Re: pgsql: Add option to use ICU as global locale provider

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...