Noah Misch <n...@leadboat.com> writes:
> On Wed, Jun 10, 2015 at 10:09:38AM -0400, Tom Lane wrote:
>> 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?
> 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].
Ah-hah.
> While Windows was the bellwether, harm potential is greater on non-Windows
> systems. pg_perm_setlocale() sets the LC_CTYPE environment variable to help
> PL/Perl avoid clobbering the process locale; see plperl_init_interp()
> comments. However, that function has bespoke code for Windows, on which
> setting the environment variable doesn't help. I don't know which other
> platforms invalidate previous setlocale() return values on setlocale(LC_CTYPE,
> NULL). Therefore, I propose committing the attached diagnostic patch and
> reverting it after about one buildfarm cycle. It will make affected
> configurations fail hard, and then I'll have a notion about the prevalence of
> damage to expect in the field.
I doubt this will teach us anything; if any buildfarm systems were
exhibiting the issue, they'd have been failing all along, no? This should
break at least the bootstrap/initdb case on any affected system.
> The actual fix is trivial, attached second. This is for back-patch to 9.4.
Looks sane to me.
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
