Re: "could not adopt C locale" failure at startup on Windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "could not adopt C locale" failure at startup on Windows
Date
Msg-id 42400.1434386263@sss.pgh.pa.us
Whole thread Raw
In response to Re: "could not adopt C locale" failure at startup on Windows  (Noah Misch <noah@leadboat.com>)
Responses Re: "could not adopt C locale" failure at startup on Windows  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> A faster test is to set LC_CTYPE=C in the environment and run "postgres
> --version".  The root cause is a bug my commit 5f538ad introduced at the start
> of the 9.4 cycle.  pg_perm_setlocale() now calls pg_bind_textdomain_codeset(),
> which calls setlocale(LC_CTYPE, NULL).  POSIX permits that to clobber all
> previous setlocale() return values, which it did here[1].

After further thought, ISTM that this bug is evidence that 5f538ad
was badly designed, and the proposed fix has blinkers on.  If
pg_bind_textdomain_codeset() is looking at the locale environment,
we should not be calling it from inside pg_perm_setlocale() at all,
but from higher level code *after* we're done setting up the whole libc
locale environment --- thus, after the unsetenv("LC_ALL") call in main.c,
and somewhere near the bottom of CheckMyDatabase() in postinit.c.
It's mere chance that the order of calls to pg_perm_setlocale() is
such that the code works now; and it's not hard to imagine future
changes in gettext, or reordering of our own code, that would break it.
So I think having to duplicate that call is a reasonable price to pay
for not having surprising entanglements in what should be a very thin
wrapper around setlocale(3).
        regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Next
From: Tom Lane
Date:
Subject: Re: fmgr.h