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

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.

> 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.

There is nothing more permanent than a temporary fix, as some say,
but I'd like to trust in something happening for hash. I'm not
planning to code that myself, though, but if somebody is willing to
work that, be it with an LLM, I would read the code.

That's just to say that I don't see a downside with including HEAD in
step 1.
--
Michael