Re: pgsql: Perform provider-specific initialization in new functions.

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Jeff Davis <jdavis(at)postgresql(dot)org>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Perform provider-specific initialization in new functions.
Date: 2026-04-13 21:08:20
Message-ID: 9e74ecd519ac5a1a2a5fefec86d261037f3db311.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On Sat, 2026-03-07 at 16:36 +0500, Andrey Borodin 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"?

That seems like excessive coupling that's hard to explain.

> > , 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.

Yeah, I'd prefer not take this approach.

> >  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.

Attached. I think this is the least-invasive patch to apply to master
now, because it doesn't change any assumptions.

The assumption "any deterministic collation will do" is still the same,
it just chooses C_COLLATION_OID rather than DEFAULT_COLLATION_OID. That
has two benefits:

1. Fixes your issue, because C_COLLATION_OID is always available.
2. Faster than a default collation based on libc or ICU.

Note that you may still have other problems trying to do interesting
things before CheckMyDatabase(), so I'm not necessarily endorsing that,
but this patch seems good regardless.

>
I don't see a reason to backport this, but if someone else does then I
could be convinced.

Thoughts?

Regards,
Jeff Davis

Attachment Content-Type Size
v1-0001-catcache.c-always-use-C_COLLATION_OID.patch text/x-patch 2.7 KB

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Amit Kapila 2026-04-14 04:11:58 pgsql: Add missing period to HINT messages.
Previous Message Jeff Davis 2026-04-13 18:34:43 pgsql: Fix overrun when comparing with unterminated ICU language string