Re: Should we remove "not fast" promotion at all?

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