Noah Misch <n...@leadboat.com> writes:
> On Tue, Jun 09, 2015 at 12:24:02PM -0400, Tom Lane wrote:
>> 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.
Oooh ... I'd forgotten that 6fdba8ceb was so recent. Agreed, what we are
seeing is probably a situation that's been there for a long time, but we
were ignoring the failure up to now (and, evidently, it wasn't really
creating any problems).
> 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.
Hm. I could understand getting encoding difficulties in that environment,
but it's hard to see why they'd manifest like this. Can you trace through
pg_perm_setlocale and figure out why it's reporting failure?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
