Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Date: 2018-03-28 03:53:44
Message-ID: CABOikdNEj6zTRdKy3eyxn_-1_PgoxRFGFEkccSy1iQ-30Xdp0A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 28, 2018 at 7:36 AM, Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2018-03-28 03:57:59 Re: PostgreSQL crashes with SIGSEGV
Previous Message Tom Lane 2018-03-28 03:53:08 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS