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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?
Дата
Msg-id 20170627184406.jnl5xuewqh3nyuoj@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On 2017-06-23 10:56:07 +0900, Michael Paquier wrote:
> > 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.

I'm far from convinced by this.  By now WAL replay with checkpointer,
bgwriter, etc. active is actually *more* tested than the cases without
it. The likelihood of bugs is higher in the less frequently exercised
paths, and given that replication exercises the situation with all those
processes active on a continuous basis, I'm fairly unconvinced by your
argument.

- Andres



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] memory layouts for binary search in nbtree
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] memory layouts for binary search in nbtree