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

From Andres Freund
Subject Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?
Date
Msg-id 20170627184406.jnl5xuewqh3nyuoj@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Fast promotion not used when doing a recovery_targetPITR restore?  (Michael Paquier <michael.paquier@gmail.com>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] memory layouts for binary search in nbtree
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] memory layouts for binary search in nbtree