Thanks for the swift reply! > On 7 Mar 2026, at 01:01, Jeff Davis <[email protected]> wrote: > > > 1. Your fix addresses it, and would also add some safety against > other edge cases we haven't caught yet. The only time it would take > effect is for very early initialization
Maybe let's sprinkle with asserts like "I'm walsender"? Or at least "I'm not a user backend"? > , but there is nonzero risk of > inconsistency because the same value would get a different hash before > and after CheckMyDatabase(). Sounds scary, actually. I heard of several corruptions that started with bogus cache entries. > 2. We could hardcode texthashfunc() to use C_COLLATION_OID. That > wouldn't match the column collation, but it would avoid the crash, and > might technically still be fine: the default collation is always > deterministic, and all deterministic collations have the same equality > semantics as "C". Even if the proper hashtext() is used somewhere else, > then it uses "C" hashing semantics for all deterministic collations. > The problem here is that we'd like to allow the default collation to be > nondeterministic in the future (Peter has mentioned this a few times), > so relying on this assumption is fragile. > > 3. We could try to include collation information in the cachinfo or > somewhere and pass it down to find the > right hash function. IMO anything less cannot be correct in a long run. Allowing random hash function is a minefield. > This feels > like a better fix, but there could be other areas we miss that are > using a catalog TEXT field with the default collation. Also it's more > invasive. > > We could decide to do your approach for now (in master and > REL_18_STABLE), and then leave #3 for the future (master only). The approach sounds fine for me. Can we be sure hash function does not change after CheckMyDatabase()? Possible coredump by authenticated user does not sound like big issue. And I never saw any report about it in the wild. Best regards, Andrey Borodin.
