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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Mar 27, 2018 at 11:41 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This is ignoring the possibility of damaged data in between, ie
>> A ... B ... CHKPT ... C ... a few zeroed pages ... D ... CHKPT ... E ... F

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

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

But really this is just one illustration of the point, which is that
changing the WAL header definition as proposed *does* cost us reliability.
We can argue about whether better concurrency in WAL insertion is
worth that price, but claiming that the price is zero is flat wrong.

For me, the more important issue is that checking xl_prev not only
validates that the record is where it is supposed to be, but that you
arrived at it correctly. Replacing it with xl_curr would keep the
guarantee of the former (in fact likely make it stronger); but we'd
completely lose the latter.

regards, tom lane