Re: Continue work on changes to recovery.conf API

On 21/11/2018 07:00, Michael Paquier wrote:
> What's bad in keeping standby_mode and just rely on recovery.signal to
> enforce recovery to happen?  When the startup process starts all the
> parameters should be loaded.  That would also need less work from users
> to switch to the new APIs.  I think that there could be a point to
> *merge* hot_standby and standby_mode actually into an enum, so keeping
> standby_mode would help with that (not this patch work of course).  The
> barrier between recovery.trigger standby.trigger is also rather thin. 

This wasn't my idea, so this is just my interpretation.  The scenario
I'm wondering about is:  You have a standby.  So (under your system) you
set standby_mode=on and create recovery.trigger.  Then you promote that
standby, so recovery.trigger is removed, but standby_mode=on stays.
Much time passes.  At some point you want to do a PITR on that instance.
 So you create a recovery.trigger, set some recovery parameters.  But
you didn't notice that standby_mode=on is still set from way back when
-- and you create a mess.

One way to think about it is: Being a standby is a state, not a
configuration setting.

Btw., I'm not in love with the *.signal naming.  I originally argued
against naming them *.trigger, but I don't like the alternative either.
But that's easy to change if someone has a better idea.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services