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

From Robert Haas
Subject Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Date
Msg-id CA+TgmoZMbPgU6VGG311UU0CLj0XO9-kSnLG+_6OH+it1_Sm=rg@mail.gmail.com
Whole thread Raw
In response to Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Pavan Deolasee <pavan.deolasee@gmail.com>)
List pgsql-hackers
On Thu, Feb 1, 2018 at 7:21 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Yes, it would be about 99% of the time.
>
> But you have it backwards - we are not assuming that case. That is the
> only case that has risk - the one where an old WAL record starts at
> exactly the place the latest one stops. Otherwise the rest of the WAL
> record will certainly fail the CRC check, since it will effectively
> have random data in it, as you say.

OK, I get it now.  Thanks for explaining.  I think I understand now
why you think this problem can be solved just by controlling the way
we recycle segments, but I'm still not sure if that can really be made
fully reliable.  Michael seems concerned about what might happen after
multiple recyclings, and Tom has raised the issue of old data
reappearing after a crash.

I do agree that it would be nice if we could make it work - saving 8
bytes per WAL record would be significant.

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Query running for very long time (server hanged) with parallel append
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Bug in to_timestamp().