Standardizing how pg_waldump presents recovery conflict XID cutoffs

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Standardizing how pg_waldump presents recovery conflict XID cutoffs
Date: 2022-11-15 18:24:05
Message-ID: CAH2-Wzm2CQUmViUq7Opgk=McVREHSOorYaAjR1ZpLYkRN7_dPw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Most recovery conflicts are generated in REDO routines using a
standard approach these days: they all call
ResolveRecoveryConflictWithSnapshot() with a latestRemovedXid argument
taken directly from the WAL record. Right now we don't quite present
this information in a uniform way, even though REDO routines apply the
cutoffs in a uniform way.

ISTM that there is value consistently using the same symbol names for
these cutoffs in every WAL record that has such a cutoff. The REDO
routine doesn't care about how the cutoff was generated during
original execution anyway -- it is always the responsibility of code
that runs during original execution (details of which will vary by
record type). Consistency makes all of this fairly explicit, and makes
it easier to use tools like pg_waldump to debug recovery conflicts --
the user can grep for the same generic symbol name and see everything.

Attached WIP patch brings heapam's VISIBLE record type and SP-GiST's
VACUUM_REDIRECT record type in line with this convention. It also
changes the symbol name from latestRemovedXid to something more
general: latestCommittedXid (since many of these WAL records don't
actually remove anything).

The patch also documents how these cutoffs are supposed to work at a
high level. We got the details slightly wrong (resulting in false
conflicts) for several years with FREEZE_PAGE records (see bugfix
commit 66fbcb0d2e for details), which seems like a relatively easy
mistake to make -- so we should try to avoid similar mistakes in the
future.

I'm not necessarily that attached to the name latestCommittedXid. It
is more accurate, but it's also a little bit too similar to another
common XID symbol name, latestCompletedXid. Can anyone suggest an
alternative?

--
Peter Geoghegan

Attachment Content-Type Size
v1-0001-Standardize-rmgrdesc-recovery-conflict-XID-output.patch application/octet-stream 45.1 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-15 18:25:16 Re: List of Bitmapset (was Re: ExecRTCheckPerms() and many prunable partitions)
Previous Message Tom Lane 2022-11-15 18:23:27 Re: List of Bitmapset (was Re: ExecRTCheckPerms() and many prunable partitions)