Re: "could not adopt C locale" failure at startup on Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: "could not adopt C locale" failure at startup on Windows
Date: 2015-06-17 17:43:55
Message-ID: 2461.1434563035@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)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

In response to

Responses

Browse pgsql-hackers by date

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