Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?
Дата
Msg-id CAB7nPqRrQ1RGsmc6kLpHHCEn9GPNjsxTE-XNAvdOtG8EZ9fmJw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Andres Freund <andres@anarazel.de>)
Ответы Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: [HACKERS] transition table behavior with inheritance appears broken
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [HACKERS] TRUE and true