From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Standby accepts recovery_target_timeline setting? |
Date: | 2019-10-02 07:30:38 |
Message-ID: | 20191002073038.GG6962@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* David Steele (david(at)pgmasters(dot)net) wrote:
> 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.
Agreed.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Smith, Peter | 2019-10-02 07:31:48 | RE: Proposal: Make use of C99 designated initialisers for nulls/values arrays |
Previous Message | Michael Paquier | 2019-10-02 07:17:15 | Re: Inconsistent usage of BACKEND_* symbols |