On Mon, 26 Oct 2026 at 08:48, Michael Paquier <[email protected]> wrote: > > Honestly, I am not convinced that it is worth bothering with the > v14~16 branches: REGBUF_NO_CHANGE does not exist there, and we would > need to identify a way to identify pin-only buffers, probably with an > exclusive lock check when a record is assembled, or something like > that. I really cannot get excited by that just for the sake of making > wal_consistency_checking able to work better for hash records there. > So let's leave it at v17~ where the regbuf flag exists.
While looking at the back-branch behavior of 27caf4ca5ae, I checked its impact on mixed minor-version replication. Since this changes what the primary writes in back branches (17–19), I wanted to check whether it needs a release note. I tested REL_18 with and without the commit, using both streaming replication and crash recovery. I found one case that fails: a primary with the commit and wal_consistency_checking enabled for hash, streaming to a standby without the commit. The new primary no longer writes a consistency image for the registered NO_CHANGE block. However, the older standby expects an image for every registered block in a flagged record. It stops at the first such record with an assertion failure in an assert build, or a FATAL error otherwise. The standby works normally after it is updated. Without wal_consistency_checking, the WAL remains unchanged. Disabling the setting on the standby does not help because the flag is part of the WAL record. This affects only users who enable wal_consistency_checking in production, but it can cause a standby to stop until it is updated. I was wondering whether we should mention this in the release notes, advising users to update standbys before primaries or disable wal_consistency_checking on the primary until all nodes are updated. Regards, Vignesh
