Re: Initdb-cs_CZ.WIN-1250 buildfarm failures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: CSPUG <info(at)cspug(dot)cz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Date: 2014-12-20 17:12:04
Message-ID: 4093.1419095524@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Noah Misch <noah(at)leadboat(dot)com> writes:
> On Sat, Dec 20, 2014 at 05:14:03PM +0100, CSPUG wrote:
>> On 20.12.2014 07:39, Noah Misch wrote:
>>> Buildfarm members magpie, treepie and fulmar went absent on
>>> 2014-10-29. Since returning on 2014-11-16, they have consistently
>>> failed with 'initdb: invalid locale name "cs_CZ.WIN-1250"'. No
>>> commits in that period readily explain a regression in this area. Did
>>> the underlying system configurations change?

That's what I'd been assuming, but I had not got round to inquiring.

>> I'm pretty sure it's because of broken locales at the system level. It was
>> working fine, and I haven't done any substantial changes to the system
>> except for occasional "yum update", so I'm unaware of what went wong :(
>>
>> The only reasons I can think of is that some of the updates required
>> a reboot, and I haven't done that because that would kill all the VMs
>> running on that HW, including the one with CLOBBER_CACHE_RECURSIVE
>> tests. And that'd throw away tests running for ~3 months.
>>
>> I've disabled the three animals (magpie, fulmar, treepie) for now, because
>> there's no point in running the tests until the locale issues are fixed. If
>> anyone has an idea of what might be wrong, let me know.

> Those animals have been successfully completing initdb for several locales,
> including en_US, before failing at cs_CZ.WIN-1250. You could disable just the
> cs_CZ.WIN-1250 steps. A CentOS 6.6 system here also lacks such a locale:

> $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC
> locale: Cannot set LC_CTYPE to default locale: No such file or directory
> locale: Cannot set LC_MESSAGES to default locale: No such file or directory
> locale: Cannot set LC_ALL to default locale: No such file or directory

FWIW, an actual RHEL 6.6 system doesn't like that either; at least not
with a fairly minimal set of locales installed.

> Perhaps an update made the system stricter about rejecting unknown locales.

Red Hat released RHEL 6.6 on Oct 14. I am not sure how long it took the
CentOS crew to follow suit, but it's well within the realm of plausibility
that when these buildfarm critters went offline it was associated with a
system update from 6.5 to 6.6 ... which was a *major* update. (On my
machine, something like 480 out of 1500 packages were updated.) It's easy
to believe that either the glibc locale code is now stricter, or that Red
Hat reshuffled the packaging a bit and the missing locale is now in a
new package that didn't get installed.

Personally I'd not have tried to run such a system without rebooting ...
it's unlikely that not rebooting has anything directly to do with this
problem, but I would not be surprised by issues elsewhere.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2014-12-20 17:13:05 Re: Initdb-cs_CZ.WIN-1250 buildfarm failures
Previous Message Steve Singer 2014-12-20 17:11:30 Re: [PATCH] HINT: pg_hba.conf changed since last config reload