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

On Tue, 27 Oct 2026 08:06:48 +0900, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> 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.
> [...] if somebody is willing to work that, be it with an LLM, I would
> read the code.

That plan works for me, and I'll take the hash rework (step 2).

Step 1 (down to v17, including HEAD): the flag-level fix we discussed,
with your comment wording. I'll post it as the next version shortly.
The one line I'd keep is the pointer from verifyBackupPageConsistency()
back to XLogRecordAssemble(), since the two have to stay in agreement
and they're far apart in the file.

Step 2 (make hash stop breaking the rule): the three sites that register
a pin-only primary/bucket page purely to force a replay cleanup lock
(hashbucketcleanup, _hash_freeovflpage, _hash_squeezebucket). The
tricky part isn't locking the page, it's doing so without losing the
replay-cleanup-lock behaviour the registration exists to produce, so the
standby still serialises against scans the same way. The
XLogSaveBufferForHint() protocol Jeff pointed at in 2024 is the model
I'll start from -- it already copes with WAL-logging a page that isn't
held exclusively. I'll post that on this thread for review before
worrying about step 3; once it's in, step 3 (re-add the assert, remove
REGBUF_NO_CHANGE) falls out.

> There is nothing more permanent than a temporary fix [...] but I'd like
> to trust in something happening for hash.

Too true!

On 2026-10-26 shihao zhong wrote:
> [btree indexing a hash of the key + recheck] users can do that today with
> expression index right?

Something else occured to me on this, the gap is the interesting bit.

You can do:

CREATE INDEX ON t (hashtext(col)) and then query
WHERE hashtext(col) = hashtext('x') AND col = 'x'

but you have to write the hash and the recheck yourself in every query,
and the planner won't use that index for a plain col = 'x'.

What Andres described is the planner doing that transparently for col =
'x' against a normal-looking index, which the expression-index approach
doesn't give you, and HOT is out of the question [0]. So it's a manual
workaround today, not the transparent feature. (Orthogonal to this
thread; just answering.)

best,

-greg

[0] https://postgr.es/m/78574B24-BE0A-42C5-8075-3FA9FA63B8FC@amazon.com