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

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: pg_rewind and xlogtemp files
Следующее
От: Thomas Munro
Дата:
Сообщение: Inheritance planner CPU and memory usage change since 9.3.2