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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()
Date: 2018-03-29 21:18:20
Message-ID: 29084.1522358300@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-03-29 21:27:47 Re: ALTER TABLE ADD COLUMN fast default
Previous Message Thomas Munro 2018-03-29 21:18:14 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS