Re: Add a guard against uninitialized default locale

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Add a guard against uninitialized default locale
Date: 2026-05-15 03:42:11
Message-ID: CAJTYsWVg5j_UA8mcNTWcQnhePxyd_DLZT7QDQv54dvcG=900Jg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, 15 May 2026 at 03:30, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> On Fri, 2026-04-24 at 15:44 -0700, Jeff Davis wrote:
> > Not known to be reachable after dbf217c1c7, but defend against
> > similar
> > issues in the future. For instance, an extension might encounter the
> > problem by calling pg_newlocale_from_collation(DEFAULT_COLLATION_OID)
> > from _PG_init(), and end up with a NULL pointer dereference.
> >
> > Backport through 17, though patch is different in 17 (also attached).
>
> I plan to commit and backport this soon.
>
>
The patch looks good to me as it is.

Just one nit in PG 17 patch:

The provider == '\0' sentinel is correct (valid
providers are 'b'/'c'/'i'/'d', all nonzero) and the three guarded
sites (lc_collate_is_c, lc_ctype_is_c, pg_newlocale_from_collation)
cover the direct consumers symmetrically. The only thing maybe
consider is replacing the bare /* should not happen */ above the
'\0' test with something like /* provider unset; init_database_-
collation() not yet run */ -- the literal '\0' check reads as a bit
magical otherwise, but maybe you are doing that to have same
comment throughout.

Regards,
Ayush

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2026-05-15 03:58:35 Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Previous Message shveta malik 2026-05-15 03:26:42 Re: Improve conflict detection when replication origins are reused