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 по дате отправления: