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
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 |