Re: pgsql: Revert online data checksum transitions

Daniel Gustafsson <dgustafsson(at)postgresql(dot)org> wrote:
> Ugh, I thought I had tested everything but clearly missed this one. Will fix immediately when back from lunch.

While you are at it: the revert removes RM_XLOG2_ID and its records but
leaves XLOG_PAGE_MAGIC at 0xD121 on REL_19_STABLE. 0xD121 was set on
2026-07-15 by b01c31eef9c, after the feature had added XLOG2 on
2026-04-03, and it is what 19beta3 shipped with. So WAL written by
19beta3 and WAL written by 19.0 now carry the same magic but are not
the same format.

To check, I enabled checksums online on 19beta3 and read the WAL with
the pg_waldump of REL_19_STABLE at d8408e8d682:

19beta3's pg_waldump -r XLOG2:
rmgr: XLOG2 ... lsn: 0/0157F5A8 ... desc: CHECKSUMS inprogress-on
rmgr: XLOG2 ... lsn: 0/02DC9AD8 ... desc: CHECKSUMS on

REL_19_STABLE's pg_waldump, same segments:
pg_waldump: error: could not find a valid record after 0/0157F5A8:
invalid resource manager ID 22 at 0/0157F5A8

REL_19_STABLE's pg_waldump with XLOG_PAGE_MAGIC bumped:
pg_waldump: error: could not find a valid record after 0/0157F5A8:
invalid magic number D121 in WAL segment 000000010000000000000001,
LSN 0/01000000, offset 0

The server itself is not at risk, since PG_CONTROL_VERSION was bumped
and 19.0 refuses a beta3 data directory; it is only tools reading
archived beta3 WAL that cannot tell the formats apart. But the revert
of 0d3dba38c77 on this branch (01a80f06214) bumped the magic for the
same reason, so it looks like this one should too. Note that master is
already at 0xD122, for a different format.

The script is attached, in case it is useful.

Regards,
Manu