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
