Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation() - Mailing list pgsql-hackers

From Pavan Deolasee
Subject Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Date
Msg-id CABOikdNEj6zTRdKy3eyxn_-1_PgoxRFGFEkccSy1iQ-30Xdp0A@mail.gmail.com
Whole thread Raw
In response to Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers


On Wed, Mar 28, 2018 at 7:36 AM, Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Mar 27, 2018 at 02:02:10PM -0400, Tom Lane wrote:

>
> Well, the point of checkpoints is that WAL data before the last one
> should no longer matter anymore, isn't it?

I have to agree with Tom here.  If you force pg_rewind to replay more
WAL records from a checkpoint older than the checkpoint prior to where
WAL has forked at promotion then you have a risk of losing data.

Yeah, we should not do that. The patch surely does not intend to replay any more WAL than what we do today. The idea is to just use a different mechanism to find the prior checkpoint. But we should surely find the latest prior checkpoint. In the rare scenario that Tom showed, we should just throw an error and fix the patch if it's not doing that already.

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Next
From: Peter Geoghegan
Date:
Subject: Re: PostgreSQL crashes with SIGSEGV