Thread: pgsql: Make crash recovery ignore recovery target settings.
Make crash recovery ignore recovery target settings. In v11 or before, recovery target settings could not take effect in crash recovery because they are specified in recovery.conf and crash recovery always starts without recovery.conf. But commit 2dedf4d9a8 integrated recovery.conf into postgresql.conf and which unexpectedly allowed recovery target settings to take effect even in crash recovery. This is definitely not good behavior. To fix the issue, this commit makes crash recovery always ignore recovery target settings. Back-patch to v12. Author: Peter Eisentraut Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net Branch ------ REL_12_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4af2ac3deeca24d3b8cb1abeb49bd62a7d013fa3 Modified Files -------------- src/backend/access/transam/xlog.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
Hi Fujii-san, On Mon, Sep 30, 2019 at 01:21:00AM +0000, Fujii Masao wrote: > Make crash recovery ignore recovery target settings. > > In v11 or before, recovery target settings could not take effect in > crash recovery because they are specified in recovery.conf and > crash recovery always starts without recovery.conf. But commit > 2dedf4d9a8 integrated recovery.conf into postgresql.conf and > which unexpectedly allowed recovery target settings to take effect > even in crash recovery. This is definitely not good behavior. > > To fix the issue, this commit makes crash recovery always ignore > recovery target settings. > > Back-patch to v12. It would be nice to avoid committing stuff into REL_12_STABLE until the version is tagged (not stamped!) as the tarball wrap for the GA of this week is going to be soon. -- Michael
Attachment
On Mon, Sep 30, 2019 at 11:45 AM Michael Paquier <michael@paquier.xyz> wrote: > > Hi Fujii-san, > > On Mon, Sep 30, 2019 at 01:21:00AM +0000, Fujii Masao wrote: > > Make crash recovery ignore recovery target settings. > > > > In v11 or before, recovery target settings could not take effect in > > crash recovery because they are specified in recovery.conf and > > crash recovery always starts without recovery.conf. But commit > > 2dedf4d9a8 integrated recovery.conf into postgresql.conf and > > which unexpectedly allowed recovery target settings to take effect > > even in crash recovery. This is definitely not good behavior. > > > > To fix the issue, this commit makes crash recovery always ignore > > recovery target settings. > > > > Back-patch to v12. > > It would be nice to avoid committing stuff into REL_12_STABLE until > the version is tagged (not stamped!) as the tarball wrap for the GA of > this week is going to be soon. I was thinking this is open item for v12 and needs to be fixed before GA. But per discussion in pgsql-release, the consensus seems to be to ship GA first and fix that after GA. Sorry for my inattention... I suspend to commit other recovery-related things until GA is tagged. Regards, -- Fujii Masao
On 9/29/19 11:02 PM, Fujii Masao wrote: > On Mon, Sep 30, 2019 at 11:45 AM Michael Paquier <michael@paquier.xyz> wrote: >> >> Hi Fujii-san, >> >> On Mon, Sep 30, 2019 at 01:21:00AM +0000, Fujii Masao wrote: >>> Make crash recovery ignore recovery target settings. >>> >>> In v11 or before, recovery target settings could not take effect in >>> crash recovery because they are specified in recovery.conf and >>> crash recovery always starts without recovery.conf. But commit >>> 2dedf4d9a8 integrated recovery.conf into postgresql.conf and >>> which unexpectedly allowed recovery target settings to take effect >>> even in crash recovery. This is definitely not good behavior. >>> >>> To fix the issue, this commit makes crash recovery always ignore >>> recovery target settings. >>> >>> Back-patch to v12. >> >> It would be nice to avoid committing stuff into REL_12_STABLE until >> the version is tagged (not stamped!) as the tarball wrap for the GA of >> this week is going to be soon. > > I was thinking this is open item for v12 and needs to be fixed before GA. > But per discussion in pgsql-release, the consensus seems to be to > ship GA first and fix that after GA. Sorry for my inattention... > I suspend to commit other recovery-related things until GA is tagged. I'm surprised that we would consider going to GA with an issue like this outstanding. -- -David david@pgmasters.net
On Mon, Sep 30, 2019 at 7:28 AM David Steele <david@pgmasters.net> wrote: > I'm surprised that we would consider going to GA with an issue like this > outstanding. Yeah, this is a *bad* problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Greetings, * Robert Haas (robertmhaas@gmail.com) wrote: > On Mon, Sep 30, 2019 at 7:28 AM David Steele <david@pgmasters.net> wrote: > > I'm surprised that we would consider going to GA with an issue like this > > outstanding. > > Yeah, this is a *bad* problem. I have to agree with this and I'm also pretty disappointed that we seem to be 'damn the torpedos, full steam ahead' with these issues. I don't like the idea of a delay either but ... Thanks, Stephen