On Fri, Mar 18, 2022 at 4:12 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
> On Fri, Mar 18, 2022 at 11:01:11AM +0900, Michael Paquier wrote:
> > FYI, prion is complaining here:
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2022-03-18%2001%3A43%3A13
> >
> > Some details:
> > # Failed test 'fails for invalid ICU locale: matches'
> > # at t/001_initdb.pl line 107.
> > # '2022-03-18 01:54:58.563 UTC [504] FATAL: could
> > # not open collator for locale "@colNumeric=lower":
> > # U_ILLEGAL_ARGUMENT_ERROR
>
> That's very strange, apparently initdb doesn't detect any problem when checking
> ucol_open() for initial checks, since it's expecting:
>
> # doesn't match '(?^:initdb: error: could not open collator for locale)'
>
> but then postgres in single-backend mode does detect the problem, with the
> exact same check, so it's not like --icu-locale=@colNumeric=lower wasn't
> correctly interpreted. Unfortunately we don't have the full initdb output, so
> we can't check what setup_locale_encoding reported. The only difference is
> that in initdb's setlocale(), the result of ucol_open is discarded, maybe the
> compiler is optimizing it away for some reason, even though it seems really
> unlikely.
>
> That being said, we could save the result and explicitly close the collator.
> That wouldn't make much difference in initdb (but may be a bit cleaner), but I
> see that there's a similar coding in createdb(), which seems like it could leak
> some memory according to ucol_close man page.
No idea what's happening here but one observation is that that animal
is running an older distro that shipped with ICU 5.0. Commit b8f9a2a6
may hold a clue...
