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
signature.asc
Description: PGP signature
