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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "could not adopt C locale" failure at startup on Windows
Дата
Msg-id 2461.1434563035@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "could not adopt C locale" failure at startup on Windows  (Noah Misch <noah@leadboat.com>)
Ответы Re: "could not adopt C locale" failure at startup on Windows
Список 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 по дате отправления:

Предыдущее
От: Gurjeet Singh
Дата:
Сообщение: Re: [PATCH] Function to get size of asynchronous notification queue
Следующее
От: Tomas Vondra
Дата:
Сообщение: pretty bad n_distinct estimate, causing HashAgg OOM on TPC-H