On 20.12.2014 18:32, Tom Lane wrote: > Tomas Vondra <t...@fuzzy.cz> writes: >> On 20.12.2014 18:13, Pavel Stehule wrote: >>> It is Microsoft encoding, - it is not available on Linux > >> Not true. It is available on Linux, and the regression tests were >> running with it for a long time (essentially from the moment magpie >> was added to the buildfarm). > > Well, you had it at one time, but it sure doesn't seem to be there now. > > I poked around in the RHEL 6.6 release notes, and found this possibly > relevant tidbit:
Ah, apparently I upgraded this VM to 6.6 - that wasn't exactly planned. > > mingw component, BZ#1063396 > > Following the deprecation of Matahari packages in Red Hat > Enterprise Linux 6.3, at which time the mingw packages were noted > as deprecated, and the subsequent removal of Matahari packages > from Red Hat Enterprise Linux 6.4, the mingw packages are now > being removed from Red Hat Enterprise Linux 6.6. > > The mingw packages will no longer be shipped in future Red Hat > Enterprise Linux 6 minor releases, nor will they receive > security-related updates. Consequently, users are advised to > uninstall any earlier releases of the mingw packages from their > Red Hat Enterprise Linux 6 systems. > > It seems plausible that a WIN-1250 locale would have been something > that would've been supplied by mingw rather than being part of > either glibc-common or any official locale package. I'm not sure how > that translates to it actively disappearing from your machine --- as > the note says, you're "advised to uninstall" mingw, but I don't think > the 6.6 update would have removed it automatically. Still, the > outlines of a theory are starting to come into focus. I don't think so. As I mentioned in the previous post, I still can create the locale, but initdb still fails with an error about ANSI_X3.4-1968 encoding. But clearly, something changed between RH 6.5 and 6.6, because on 6.5 I get this: $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC , � 3;3 44 160 CP1250 while on 6.6 I get this: $ LANG=cs_CZ.WIN-1250 locale LC_NUMERIC , 3;3 44 160 ANSI_X3.4-1968 So yeah, the locale definition did change a bit - the encoding is different, and we can't cope with it. > Immediate recommendation is to restart the buildfarm critters with > the missing locale removed from their configurations. If you can find > the locale again somewhere, by all means re-enable it, but better > less testing than no testing in the meantime. I've removed cs_CZ.WIN-1250 and sk_SK.WIN-1250 from the config. Let's see how that works. Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
