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

On 2026-10-27 08:06:48 +0900, Michael Paquier wrote:
> On Mon, Oct 26, 2026 at 09:46:18AM -0400, Andres Freund wrote:
> > 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.
>
> I'm definitely not convinced that hash is a sufficient argument for
> having more infrastructure. What this is telling us here is the
> contrary: we should have less infrastructure. So I'd love to be able
> to put REGBUF_NO_CHANGE in the garbage bin and have an assert in the
> replay code instead of silently ignoring a case.

Agreed.

> > 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.
>
> I'm not sure that I can side with your argument here. Doing nothing
> on master means that we're still open to the CRC problem until we
> decide to fix hash, so it still looks like a problem that needs to be
> tackled in three steps:
> - Avoid the CRC problem down to v17, including HEAD.
> - Address hash to avoid the rule breakage.
> - Lift the check in replay for wal_consistency_checking (re-add the
> assert) and push REGBUF_NO_CHANGE into orbit.

Fair enough. I guess I'd hoped that one of the folks involved in adding the
hash index WAL logging would chime in and fix this properly.

> There is nothing more permanent than a temporary fix, as some say,
> but I'd like to trust in something happening for hash.

I guess I don't have that trust in this case. This IIRC isn't the first
complaint about the odd locking stuff that hash has.

Ceterum censeo index access/hash esse delendum.

Greetings,

Andres Freund