Re: Standby accepts recovery_target_timeline setting?

Greetings,

* David Steele (david@pgmasters.net) wrote:
> On 9/28/19 1:26 PM, Fujii Masao wrote:
> > On Sun, Sep 29, 2019 at 12:51 AM David Steele <david@pgmasters.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.

Agreed.

Thanks,

Stephen