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

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-16 11:30:50
Message-ID: 20150616113050.GA372457@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jun 15, 2015 at 08:47:12AM -0400, Tom Lane wrote:
> Noah Misch <noah(at)leadboat(dot)com> writes:
> > 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?

No; most systems let environment variables carry arbitrary strings of non-nul
bytes, so they don't see $SUBJECT. I want to probe for all systems that are
currently issuing putenv("LC_CTYPE=<garbage>"), not just the ones where a
picky putenv() illuminates it.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-06-16 11:43:47 Re: 9.5 release notes
Previous Message Syed, Rahila 2015-06-16 10:04:46 Re: [Proposal] More Vacuum Statistics