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