Re: pgsql: Revert online data checksum transitions

On 16 Sep 2026, at 13:01, Fujii Masao <masao.fujii@gmail.com> wrote:

On Wed, Sep 16, 2026 at 6:06 PM Daniel Gustafsson
<dgustafsson@postgresql.org> wrote:

Revert online data checksum transitions

It's unfortunate that this feature had to be reverted...
Anyway, thanks for all your hard work on it!!

After the revert, the buildfarm member longfin reported the test failure [1],
which seems to have been caused by the revert.

According to longfin's server log, the test triggers the following
assertion failure:

TRAP: failed Assert("(data - start) == data_size"), File:
"heaptuple.c", Line: 442, PID: 78459
...
2026-09-16 06:03:57.172 EDT [77693:4] LOG: client backend (PID
78459) was terminated by signal 6: Abort trap: 6
2026-09-16 06:03:57.172 EDT [77693:5] DETAIL: Failed process was
running: SELECT count(*) > 0 AS ok FROM pg_control_checkpoint();

After the revert, pg_control_checkpoint() now returns 19 columns, but its
pg_proc.dat entry still declares 20 output columns, including
data_page_checksum_version. This seems to trigger the assertion failure
in heap_form_tuple().

We should remove data_page_checksum_version from the pg_control_checkpoint
entry in pg_proc.dat and reduce proargmodes from 20 output columns to 19?

Ugh, I thought I had tested everything but clearly missed this one. Will fix immediately when back from lunch.

./daniel

Hi Daniel,

[...]

We should remove data_page_checksum_version from the pg_control_checkpoint
entry in pg_proc.dat and reduce proargmodes from 20 output columns to 19?

Ugh, I thought I had tested everything but clearly missed this one. Will fix immediately when back from lunch.

I noticed that the revert was applied to REL_19_STABLE but not the
master branch. Just wanted to make sure that's the plan.

--
Best regards,
Aleksander Alekseev

On 16 Sep 2026, at 14:32, Aleksander Alekseev <aleksander@tigerdata.com> wrote:

We should remove data_page_checksum_version from the pg_control_checkpoint
entry in pg_proc.dat and reduce proargmodes from 20 output columns to 19?

Ugh, I thought I had tested everything but clearly missed this one. Will fix immediately when back from lunch.

I noticed that the revert was applied to REL_19_STABLE but not the
master branch. Just wanted to make sure that's the plan.

That's indeed the plan. The remaining issue that a user can, under the right
set of circumstances, get a false positive page verification in an orphaned
file failure during base backup. The warning is harmless for data integrity,
but is non-trivial for the user to resolve since we don't provide any tools for
dealing with orphaned files. Fixing this in master will reduce churn.

--
Daniel Gustafsson

Daniel Gustafsson <dgustafsson@postgresql.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

On 16 Sep 2026, at 14:58, Manuel Reyes Bravo <manuelreyesbravo@gmail.com> wrote:

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.

Thanks for the report, will include when fixing.

--
Daniel Gustafsson