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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, 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-27 17:48:57
Message-ID: CA+Tgmoa_rikAC7WxNoR5zyCm5QiD=H1-uQ6K-uTb2OJV-9BodQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com> writes:
>> On Tue, Mar 27, 2018 at 7:28 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> If you have to search backwards, this breaks it. Full stop.
>
>> We don't really need to fetch the previous record. We really need to find
>> the last checkpoint prior to a given LSN. That can be done by reading WAL
>> segments forward. It can be a little slow, but hopefully not a whole lot.
>
> This is ignoring the possibility of damaged data in between, ie
>
> A ... B ... CHKPT ... C ... a few zeroed pages ... D ... CHKPT ... E ... F
>
> If A is the start of the WAL segment, and you ask what's the last
> checkpoint before F, you will get the wrong answer. Or, if you're
> paranoid and verify that you can follow the chain all the way to F,
> you'll fail ... needlessly, and in a case where we previously succeeded.

It's hard for me to believe that this case matters very much. If
you're trying to run pg_rewind on a system where the WAL segments
contain a few zeroed pages, you're probably going to be hosed anyway,
if not by this particular thing then by something else.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-03-27 17:54:35 Re: [HACKERS] path toward faster partition pruning
Previous Message Jesper Pedersen 2018-03-27 17:46:49 Re: [HACKERS] path toward faster partition pruning