Re: Continue work on changes to recovery.conf API

On Wed, Nov 21, 2018 at 12:58:19PM +0100, Peter Eisentraut wrote:
> 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.

Very good point, I have not thought of this problem from this
perspective. Indeed that can be confusing. Now things get reset
once recovery.conf is renamed.

> 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.

Using "recovery" or "signal" would be more consistent with the existing
"promote" but that does not feel good either. "trigger" does not sound
that bad...

One extra thing I was wondering is if if would make sense to rename the
signal (or trigger files) to .done once recovery is over. That's
useful for debugging. That could always be refined later..
--
Michael