Hi,
I understood it's too late to change the feature.
I hope it will be revised in 9.4!
(2013/08/09 4:13), Josh Berkus wrote:
> On 08/08/2013 11:01 AM, Andres Freund wrote:
>
>> I don't think anybody working on related areas of the code thinks it's
>> rock solid.
>> But anyway, I just don't see the downside of allowing problem
>> analysis. You're free to do more testing, review, whatever before the
>> release.
>
> I'm 100% with you that we ought to keep the slow failover code around
> and accessible to debugging. What I'm asking is whether it should still
> be explicitly available to users, and the default. Based on your
> feedback, it's sounding like it should be.
>
In my opinion, the default behavior "fast promote" is ok.
Because we don't have any explicit problem with it for now.
And we shouldn't mention about "normal promote" in document.
I think it will make user confused if do so.
By the way, I'm thinking about when these trigger files(*)
are unlinked.
(*)Now I treat these three files
1) a file specified in trigger_file
2) ${PGDATA}/promote
3) ${PGDATA}/fast_promote
Current source has a problem in some corner cases.
It occurs by the timing of detecting these files.
for example:
------
case1:
createing 1) and executing "pg_ctl promote" occur at the same time.
case2:
creating 1) and promoting at recovery-end(by recovery_target_xxx)
occur at the same time.
------
1) is created, but promoting completes by another trigger.
Both cases 1) remains on the server.
If user doesn't know it and make a standby on the server,
the standby will promote soon.
I think this is not so big problem, but not user-friendly.
Against this, I'm thinking unlinking these files before
starting recovery.
This should be fixed in 9.4 too?
---------
Tomonari Katsumata
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
