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

From Noah Misch
Subject Re: "could not adopt C locale" failure at startup on Windows
Date
Msg-id 20150617122413.GA397033@tornado.leadboat.com
Whole thread Raw
In response to Re: "could not adopt C locale" failure at startup on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: "could not adopt C locale" failure at startup on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
> 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.

pg_bind_textdomain_codeset() looks at one piece of the locale environment,
namely setlocale(LC_CTYPE, NULL), so the order of pg_perm_setlocale() calls
does not affect it.  There's nothing acutely bad about the alternative you
identify here, but it's no better equipped to forestall mistakes.  Moving the
call later would slightly expand the window during which translated messages
are garbled.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_rewind and xlogtemp files
Next
From: Thomas Munro
Date:
Subject: Inheritance planner CPU and memory usage change since 9.3.2