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

From Tomas Vondra
Subject Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()
Date
Msg-id 1ac2dbe5-66ef-7cce-79cb-9140a0776a45@2ndquadrant.com
Whole thread Raw
In response to Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers

On 03/29/2018 11:18 PM, Tom Lane wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> If each WAL record has xl_curr, then we know to which position the
>> record belongs (after verifying the checksum). And we do know the size
>> of each WAL record, so we should be able to deduce if two records are
>> immediately after each other.
> 
> Per my point earlier, XLOG_SWITCH is sufficient to defeat that argument.

But the SWITCH record will be the last record in the WAL segment (and if
there happens to be a WAL record after it, it will have invalid xl_curr
pointer). And the next valid record will be the first one in the next
WAL segment. So why wouldn't that be enough information?

> Also consider a timeline fork.  It's really hard to be sure which record
> in the old timeline is the direct ancestor of the first one in the new
> if you lack xl_prev:
> 
>     A1 -> B1 -> C1 -> D1
>         \
>           B2 -> C2 -> D2
> 
> If you happened to get confused and think that C2 is the first in its
> timeline, diverging off the old line after B1 not A1, there would be
> nothing about C2 to disabuse you of your error.

Doesn't that mean the B1 and B2 have to be exactly the same size?
Otherwise there would be a gap between B1/C2 or B2/C1, and the xl_curr
would be enough to detect this.

And how could xl_prev detect it? AFAIK XLogRecPtr does not include
TimeLineID, so xl_prev would be the same for both B1 and B2.

I admit WAL internals are not an are I'm particularly familiar with,
though, so I may be missing something utterly obvious.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: csv format for psql
Next
From: Andres Freund
Date:
Subject: Re: Proposal: http2 wire format