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
relatedareas 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
keepthe slow failover code around> and accessible to debugging. What I'm asking is whether it should still> be
explicitlyavailable 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