On 22.04.2013 10:58, Simon Riggs wrote:
On 22 April 2013 08:13, Heikki Linnakangas<hlinnakan...@vmware.com> wrote:
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:
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
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?
Hmm. That requires write access to $DATADIR, so that's not quite the
same thing as the trigger_file recovery.conf option. But if you really
want to keep the 'slow' option, we could add an option to recovery.conf
for it. I'm thinking something like this:
trigger_file = '/mnt/foo/trigger' # file to watch for
trigger_file_method = 'slow' # slow / fast, 'fast' is default.
You would have to decide which method to use when you create
recovery.conf file, rather than when you promote, but I think that would OK.
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.
Sounds good to me.
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.
Ok. As long as 'fast' is the default and you get the same functionality
with the trigger file method and pg_ctl promote, that works for me.
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: