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