Re: Collation versioning

On Tue, Nov 3, 2020 at 6:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > Hmm, a failure from dory (WIndows) during pg_upgrade:
>
> > performing post-bootstrap initialization ... 2020-11-02 08:08:22.213
> > EST [5392] FATAL: could not get collation version for locale
> > "English_United States.1252": error code 87
>
> > 87 means invalid parameter. I'm surprised it got through various
> > other tests and then failed here. Whelk (also Windows) passed using
> > "German_Germany.1252". Hmm. I'll wait for more Windows systems to
> > report.
>
> drongo just did it too, and it seems repeatable on dory. I'm not 100%
> sure, but I think the buildfarm's initial "check" step may be run under C
> locale while pg_upgrade sees whatever the machine's prevailing locale is.
> If that's correct, it seems like the simplest explanation is just that
> extraction of a collation version is busted for (some?) non-C locales on
> Windows. Could be something as dumb as spaces in the locale name
> being problematic.

Fortunately David Rowley is able to repro this on his Windows box (it
fails even with strings that are succeeding on the other BF machines),
so we have something to work with. The name mangling that is done in
get_iso_localename() looks pretty interesting... It does feel a bit
like there is some other hidden environmental factor or setting here,
because commit 352f6f2df60 tested OK on Juan Jose's machine too.
Hopefully more soon.