Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore? - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?
Date
Msg-id CAB7nPqRrQ1RGsmc6kLpHHCEn9GPNjsxTE-XNAvdOtG8EZ9fmJw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Fri, Jun 23, 2017 at 2:34 AM, Andres Freund <andres@anarazel.de> wrote:
> I don't think it's really a bug - just a missed optimization.  I'd
> personally not be in favor of backpatching this - it'll have some chance
> of screwing things up, even if I hope that chance is fairly small.

It would be better to wait until the branch for PG11 opens then.

> As a wider discussion, I wonder if we should keep non-fast promotion for
> anything but actual crash recovery?

Yes, I would push a bit forward and remove fallback_promote.

> And even there it might actually be
> a pretty good idea to not force a full checkpoint - getting up fast
> after a crash is kinda important..

But not that. Crash recovery is designed to be simple and robust, with
only the postmaster and the startup processes running when doing so.
Not having the startup process doing by itself checkpoints would
require the need of the bgwriter, which increases the likelihood of
bugs. In short, I don't think that improving performance is the matter
for crash recovery, robustness and simplicity are.
-- 
Michael



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: [HACKERS] transition table behavior with inheritance appears broken
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: [HACKERS] TRUE and true