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

On 03/29/2018 11:18 PM, Tom Lane wrote:
> Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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