On Tue, Jun 09, 2015 at 12:24:02PM -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > The error seems odd. The only even remotely related change between 9.4.1
> > and .2 seems to be ca325941. Could also be a build environment change.
>
> Yeah, my first instinct was to blame ca325941 as well, but I don't think
> any of that code executes during init_locale(). Also,
> http://www.postgresql.org/message-id/20150326040321.2492.24...@wrigleys.postgresql.org
> says it's been seen in 9.4.1.
The return value check and error message were new in 9.4.1. I suspect the
underlying problem has been present far longer, undetected.
I can reproduce this with "initdb --locale=C",
postgresql-9.4.3-1-windows-binaries.zip (32-bit), Windows 7 x64, and the
Windows ANSI code page set to CP936. (Choose "Chinese (Simplified, PRC)" in
Control Panel -> Region and Language -> Administrative -> Language for
non-Unicode programs.) It is neither necessary nor sufficient to change
Control Panel -> Region and Language -> Formats -> Format. Binaries from
postgresql-9.4.3-1-windows-x64-binaries.zip do not exhibit the problem. Note
that CP936 is a PG_ENCODING_IS_CLIENT_ONLY() encoding.
> What I plan to do is this:
>
> static void
> init_locale(const char *categoryname, int category, const char *locale)
> {
> if (pg_perm_setlocale(category, locale) == NULL &&
> pg_perm_setlocale(category, "C") == NULL)
> elog(FATAL, "could not adopt either \"%s\" locale or C locale for
> %s", locale, categoryname);
> }
Good to have.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
