We never reached a consensus on the user interface of the new 'fast
promotion'. We should settle that before beta. The thread died here:
http://www.postgresql.org/message-id/CA+U5nMKmDD7hGCYzOo=iFM=eK5OPDXCEzmq79fgLWr0TJk=s...@mail.gmail.com
Simon said in that email that he's waiting for further comments, so let
me reiterate my view on this:
The current situation is that to do 'fast promotion', you have to use
"pg_ctl promote -m fast". 'slow' promotion is the default.
I didn't like that, because:
1. The slow method has no advantage over the fast method. Therefore I
think the fast method should be the default, when promoting a standby.
To be conservative, just in case there are bugs in the fast method, we'd
still use the slow method for crash recovery and end of point-in-time
recovery. That provides an escape hatch, so that if the fast method
fails because of a bug, you can still start up the database.
2. There is no way to perform 'fast promotion' using the trigger file.
That feature is only available using "pg_ctl promote". When "pg_ctl
promote" was introduced, it was not meant to replace the trigger file
method, as that is also very useful in many situations. (as explained
here: http://www.postgresql.org/message-id/5112a54b.8090...@vmware.com)
Putting points 1 and 2 together, I think the best solution is to always
perform 'fast' promotion when in standby mode, and remove pg_ctl -m
fast/smart option altogether. There is no need to expose that to users.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
