Re: "could not adopt C locale" failure at startup on Windows - Mailing list pgsql-hackers

From Noah Misch
Subject Re: "could not adopt C locale" failure at startup on Windows
Date
Msg-id 20150616113050.GA372457@tornado.leadboat.com
Whole thread Raw
In response to Re: "could not adopt C locale" failure at startup on Windows  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jun 15, 2015 at 08:47:12AM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.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.



pgsql-hackers by date:

Previous
From: "Syed, Rahila"
Date:
Subject: Re: [Proposal] More Vacuum Statistics
Next
From: Bruce Momjian
Date:
Subject: Re: 9.5 release notes