From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fast promotion, loose ends |
Date: | 2013-04-22 07:58:57 |
Message-ID: | CA+U5nMKbBVbw7yGrn49u9jkJrWu417kDh_WjdWcWnjCU42jKtA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22 April 2013 08:13, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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=sXw@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.8090500@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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-04-22 08:29:33 | Re: Fast promotion, loose ends |
Previous Message | Heikki Linnakangas | 2013-04-22 07:13:37 | Fast promotion, loose ends |