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

Hi,

On 2026-10-26 12:17:55 +0900, Michael Paquier wrote:
> > 2. Jeff asked why hash can't just follow the rules and exclusive-lock +
> > dirty the buffer. That is the better long-term answer, but it is a
> > non-trivial rework of the hash cleanup/squeeze locking and does not
> > back-patch cleanly. The attached fix is the minimal, back-patchable
> > change and does not foreclose the rework.
>
> I'm still wondering if this would not be the best thing long-term.
> Perhaps not, so [shrug].

I frankly think it's pretty much unacceptable for a niche index like hash to
violate the rules like that. If it were btree, it'd perhaps be worthwhile to
add generic infrastructure for this, but here it doesn't seem like the juice
is worth the squeeze.

> As of this commit, never take an image for a REGBUF_NO_CHANGE buffer, even
> under XLR_CHECK_CONSISTENCY. There is no need to do a consistency check on
> a block not changed by a record. verifyBackupPageConsistency() is taught to
> skip a registered block that carries no image rather than asserting one
> should be present.

I'm not really convinced by that argument. It's probably the best answer in
the back branches, but I think we shouldn't do this in master.

Greetings,

Andres Freund