Re: "could not adopt C locale" failure at startup on Windows
| От | Noah Misch |
|---|---|
| Тема | Re: "could not adopt C locale" failure at startup on Windows |
| Дата | |
| Msg-id | 20150616113050.GA372457@tornado.leadboat.com обсуждение |
| Ответ на | Re: "could not adopt C locale" failure at startup on Windows (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | 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 по дате отправления: