On 22 April 2013 08:13, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > 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:
I'm very happy to discuss this some more, thanks for bringing it up. > 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. In general, I agree. My only "advantage" for slow is that we know it works. > 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) I realise that it *is* possible to trigger fast promotion using a file, since that is exactly the method we use to implement the feature by pg_ctl. In fact, pg_ctl promote is just a nice paint job over the trigger file concept. So, to initiate promotion, you can create a file called $DATADIR/fast_promote or $DATADIR/promote Does that solve the issue? > 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. We can make pg_ctl promote write the fast_promote file by default and remove the command line option altogether. I would like to retain the option to promote with a full checkpoint, for safety reasons, so continue to use both fast_promote and promote files under the covers. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
