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

From Tom Lane
Subject Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Date
Msg-id 29084.1522358300@sss.pgh.pa.us
Whole thread Raw
In response to Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Changing WAL Header to reduce contention duringReserveXLogInsertLocation()
Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
List pgsql-hackers
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.
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.

Now, those cases could be fixed: you could imagine inserting a
"continuation record" after an XLOG_SWITCH or timeline fork, which would
carry a checkable back-link to where it came from, and then we'd arguably
not need to pay the price of back-links during normal sequential
insertion.  Still, this approach only fixes the cases where we think to
apply it in advance.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS
Next
From: Tom Lane
Date:
Subject: Re: ALTER TABLE ADD COLUMN fast default