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 2461.1434563035@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:
> On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
>> 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.

Well, my point is that that is a larger assumption about the behavior of
pg_bind_textdomain_codeset() than I think we ought to make, even if it
happens to be true today.

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

I'm not exactly sure that they wouldn't be garbled anyway during the
interval where we're setting these things up.  Until DatabaseEncoding,
ClientEncoding, and gettext's internal notions are all in sync, we
are at risk of that type of issue no matter what.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: [PATCH] Function to get size of asynchronous notification queue
Next
From: Tomas Vondra
Date:
Subject: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H