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

On 2026-10-26 Andres Freund wrote:
> I think they're almost unused and don't offer enough advantage over btree
> (and perform catastrophically bad in many cases). Instead of making them WAL
> logged a few years back; we should have just ripped them out.

Fair, whether hash earns its place is a bigger conversation than this
bug. I'll just note one data point from the other thread I have open: a
good part of the "catastrophically bad in many cases" is the metapage
tuple counter serialising every insert on one buffer, and that looks
removable. Inserts stop touching the metapage on the common path and
hash then scales like btree on a concurrent insert workload in my
measurements. That doesn't change your conclusion about large-key
handling, but it does move some of the "performs badly" into "performed
badly".

> The advantage hash does have, i.e. large key handling, would have better been
> addressed by adding support to transparently btree indexing a hash of the key
> + recheck.

No disagreement that that would have been the better design. It's not
where we are, though, and ripping out a shipped, WAL-logged,
user-visible AM is its own multi-release project.

Which leaves the thing this thread actually needs a decision on,
independent of hash's long-term fate: master faults a standby under
wal_consistency_checking='hash' today. The one-line fix (skip the
full-page image for a REGBUF_NO_CHANGE block, which contradicts the
flag's own contract to take) stops that and Michael's OK with it for
v17+. You'd said you'd rather master wait for the proper hash rework.

I'm fine either way, but if master isn't getting the flag-level fix now,
I'd like the rework to be the tracked item for master rather than a
someday, the crash is live on master. So: flag fix in master now plus
rework as follow-up, or rework-only for master?

I'll build whichever, I just don't want it to stall into neither.

best,

-greg