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

Noah Misch <noah@leadboat.com> writes:
> A faster test is to set LC_CTYPE=C in the environment and run "postgres
> --version".  The root cause is a bug my commit 5f538ad introduced at the start
> of the 9.4 cycle.  pg_perm_setlocale() now calls pg_bind_textdomain_codeset(),
> which calls setlocale(LC_CTYPE, NULL).  POSIX permits that to clobber all
> previous setlocale() return values, which it did here[1].

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.
So I think having to duplicate that call is a reasonable price to pay
for not having surprising entanglements in what should be a very thin
wrapper around setlocale(3).
        regards, tom lane