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
