Re: Standby accepts recovery_target_timeline setting?

On 9/28/19 1:26 PM, Fujii Masao wrote:
> On Sun, Sep 29, 2019 at 12:51 AM David Steele <david(at)pgmasters(dot)net> wrote:
>
> Yeah, more checks would be necessary. IMO easy fix is to forbid not only
> recovery target parameters but also any recovery parameters (specified
> in recovery.conf in previous versions) in crash recovery.
>
> In v11 or before, any parameters in recovery.conf cannot take effect in
> crash recovery because crash recovery always starts without recovery.conf.
> But in v12, those parameters are specified in postgresql.conf,
> so they may take effect even in crash recovery (i.e., when both
> recovery.signal and standby.signal are missing). This would be the root
> cause of the problems that we are discussing, I think.
>
> There might be some recovery parameters that we can safely use
> even in crash recovery, e.g., maybe recovery_end_command
> (now, you can see that recovery_end_command is executed in
> crash recovery in v12). But at this stage of v12, it's worth thinking to
> just cause crash recovery to exit with an error when any recovery
> parameter is set. Thought?

I dislike the idea of crash recovery throwing fatal errors because there
are recovery settings in postgresql.auto.conf. Since there is no
defined mechanism for cleaning out old recovery settings we have to
assume that they will persist (and accumulate) more or less forever.

> Or if that change is overkill, alternatively we can make crash recovery
> "ignore" any recovery parameters, e.g., by forcibly disabling
> the parameters.

I'd rather load recovery settings *only* if recovery.signal or
standby.signal is present and do this only after crash recovery is
complete, i.e. in the absence of backup_label.

I think blindly loading recovery settings then trying to ignore them
later is pretty much why we are having these issues in the first place.
I'd rather not extend that pattern if possible.

Regards,
--
-David
david(at)pgmasters(dot)net