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

From: Noah Misch <noah(at)leadboat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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 12:24:13
Message-ID: 20150617122413.GA397033@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2015-06-17 13:32:58 Inheritance planner CPU and memory usage change since 9.3.2
Previous Message Michael Paquier 2015-06-17 12:21:46 Re: pg_rewind and xlogtemp files