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

Hi,

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=(at)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.