Re: WAL record CRC calculated incorrectly because of underlying buffer modification

On Mon, 26 Oct 2026 at 08:48, Michael Paquier <michael(at)paquier(dot)xyz> 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