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