Обсуждение: ICU warnings during make installcheck and text_extensions test

Greetings, everyone!

When you try to run installcheck using a cluster that was initialized 
with ICU (./initdb -D ../data --locale-provider=icu 
--icu-locale='en_US_POSIX') and NO_LOCALE=1 you get a warning:

    # +++ regress install-check in src/test/regress +++
    # using postmaster on Unix socket, default port
    WARNING:  could not convert locale name "C" to language tag: 
U_ILLEGAL_ARGUMENT_ERROR
    WARNING:  ICU locale "C" has unknown language "c"
    HINT:  To disable ICU locale validation, set the parameter 
"icu_validation_level" to "disabled".

This happens with PostgreSQL 16, 17 and master

While this case is somewhat superficial (you need ICU and NO_LOCALE), 
when you try to run installcheck of test_extensions test module (using a 
cluster initialized with ICU) you will get the same warnings due to 
NO_LOCALE=1 in Makefile

There could be an argument "if you are using ICU and don't want warnings 
just set icu_validation_level=disabled in postgresql.conf", but then 
installcheck fails because of collate.icu.utf8 like this:

    CREATE COLLATION testx (provider = icu, locale = 
'@colStrength=primary;nonsense=yes'); DROP COLLATION testx;
    -WARNING:  could not convert locale name 
"@colStrength=primary;nonsense=yes" to language tag: 
U_ILLEGAL_ARGUMENT_ERROR
    CREATE COLLATION testx (provider = icu, locale = 'nonsense-nowhere'); 
DROP COLLATION testx;
    -WARNING:  ICU locale "nonsense-nowhere" has unknown language 
"nonsense"
    -HINT:  To disable ICU locale validation, set the parameter 
"icu_validation_level" to "disabled".
    CREATE COLLATION test4 FROM nonsense;

And we definitely want to check warnings there

So for now I propose adding icu_validation_level=disabled to pg_regress 
when we were passed NO_LOCALE=1 (patch is attached)

Also since locale 'C' isn't converted to anything with ICU since 
f3a01af, maybe we want to somehow handle NO_LOCALE with ICU in a special 
way? Maybe only during tests?

On another none, test test_extensions from 
src/test/modules/test_extensions fails during installcheck when the 
cluster was initialized with ICU locale. It was already reported at [1]. 
This test fails on current REL_17_STABLE (2530367) and master (2a5e709)

One way to fix it is to just skip the test if we find ICU locale 
provider (patch attached bellow), but I'm not sure this is the optimal 
way. In [1] there was an attempt to replace \dx+ with function with 
collation-independent output

[1] 
https://www.postgresql.org/message-id/a2fd691f8d9f1325cec1283b161d6a8e@postgrespro.ru

Hi, Oleg!

On Mon, Mar 31, 2025 at 9:48 AM Oleg Tselebrovskiy
<o.tselebrovskiy@postgrespro.ru> wrote:
> When you try to run installcheck using a cluster that was initialized
> with ICU (./initdb -D ../data --locale-provider=icu
> --icu-locale='en_US_POSIX') and NO_LOCALE=1 you get a warning:
>
>         # +++ regress install-check in src/test/regress +++
>         # using postmaster on Unix socket, default port
>         WARNING:  could not convert locale name "C" to language tag:
> U_ILLEGAL_ARGUMENT_ERROR
>         WARNING:  ICU locale "C" has unknown language "c"
>         HINT:  To disable ICU locale validation, set the parameter
> "icu_validation_level" to "disabled".
>
> This happens with PostgreSQL 16, 17 and master
>
> While this case is somewhat superficial (you need ICU and NO_LOCALE),
> when you try to run installcheck of test_extensions test module (using a
> cluster initialized with ICU) you will get the same warnings due to
> NO_LOCALE=1 in Makefile
>
> There could be an argument "if you are using ICU and don't want warnings
> just set icu_validation_level=disabled in postgresql.conf", but then
> installcheck fails because of collate.icu.utf8 like this:
>
>         CREATE COLLATION testx (provider = icu, locale =
> '@colStrength=primary;nonsense=yes'); DROP COLLATION testx;
>         -WARNING:  could not convert locale name
> "@colStrength=primary;nonsense=yes" to language tag:
> U_ILLEGAL_ARGUMENT_ERROR
>         CREATE COLLATION testx (provider = icu, locale = 'nonsense-nowhere');
> DROP COLLATION testx;
>         -WARNING:  ICU locale "nonsense-nowhere" has unknown language
> "nonsense"
>         -HINT:  To disable ICU locale validation, set the parameter
> "icu_validation_level" to "disabled".
>         CREATE COLLATION test4 FROM nonsense;
>
> And we definitely want to check warnings there
>
> So for now I propose adding icu_validation_level=disabled to pg_regress
> when we were passed NO_LOCALE=1 (patch is attached)
>
> Also since locale 'C' isn't converted to anything with ICU since
> f3a01af, maybe we want to somehow handle NO_LOCALE with ICU in a special
> way? Maybe only during tests?
>
> On another none, test test_extensions from
> src/test/modules/test_extensions fails during installcheck when the
> cluster was initialized with ICU locale. It was already reported at [1].
> This test fails on current REL_17_STABLE (2530367) and master (2a5e709)
>
> One way to fix it is to just skip the test if we find ICU locale
> provider (patch attached bellow), but I'm not sure this is the optimal
> way. In [1] there was an attempt to replace \dx+ with function with
> collation-independent output

Thank you for raising this issue.  I don't think ignoring a warning is
an option.  The tests contain locale-sensitive orderings.  Thus, if we
don't manage to create a C-like locale, tests fail anyway for me.
Ignoring tests is an unfavorable solution.

I see two (better) options to resolve this issue:
1) Specify LOCALE_PROVIDER='builtin' in the CREATE DATABASE command.
2) Specify 'en-US-u-va-posix' as a locale name when template0 has an
ICU locale provider.

The #1 looks simpler.  The patch is attached.  What do you think?

------
Regards,
Alexander Korotkov
Supabase

Alexander Korotkov wrote at 2025-07-28 20:04:
> Hi, Oleg!
> 
> Thank you for raising this issue.  I don't think ignoring a warning is
> an option.  The tests contain locale-sensitive orderings.  Thus, if we
> don't manage to create a C-like locale, tests fail anyway for me.
> Ignoring tests is an unfavorable solution.
> 
> I see two (better) options to resolve this issue:
> 1) Specify LOCALE_PROVIDER='builtin' in the CREATE DATABASE command.
> 2) Specify 'en-US-u-va-posix' as a locale name when template0 has an
> ICU locale provider.
> 
> The #1 looks simpler.  The patch is attached.  What do you think?
> 
> ------
> Regards,
> Alexander Korotkov
> Supabase

Thanks for your response!

Your patch works with REL_17 & master, but not with REL_16, since there 
is no builtin provider

So if we're going that route, for PostgreSQL 16 and older we could just 
use libc provider instead of builtin for the same effect (see attached)

I've run installcheck-world for both 'builtin' and 'libc', both seem to 
work fine

Dunno what about tests like collate.icu.utf8.sql that require icu 
databases to run. Will those tests be run if we force non-icu locale 
providers in pg_regress? We probaly want them to be run sometimes, 
right? Except this, LGTM

Regards, Oleg Tselebrovskiy

On Tue, Jul 29, 2025 at 12:45 PM Oleg Tselebrovskiy
<o.tselebrovskiy@postgrespro.ru> wrote:
> Thanks for your response!
>
> Your patch works with REL_17 & master, but not with REL_16, since there
> is no builtin provider
>
> So if we're going that route, for PostgreSQL 16 and older we could just
> use libc provider instead of builtin for the same effect (see attached)
>
> I've run installcheck-world for both 'builtin' and 'libc', both seem to
> work fine

Great.  I'm not sure if we want this to be backpatched.  Yet pushed
this to master.

> Dunno what about tests like collate.icu.utf8.sql that require icu
> databases to run. Will those tests be run if we force non-icu locale
> providers in pg_regress? We probaly want them to be run sometimes,
> right? Except this, LGTM

collate.icu.utf8.sql have a protection against running in
inappropriate locale in the top.  It's OK to run it with any locale.
If the locale doesn't match then it will be stopped in the beginning
and alternative output collate.icu.utf8_1.out matched.

------
Regards,
Alexander Korotkov
Supabase

Alexander Korotkov wrote at 2025-09-14 00:59:
> collate.icu.utf8.sql have a protection against running in
> inappropriate locale in the top.  It's OK to run it with any locale.
> If the locale doesn't match then it will be stopped in the beginning
> and alternative output collate.icu.utf8_1.out matched.

Thanks for the info!

> Great.  I'm not sure if we want this to be backpatched.  Yet pushed
> this to master.

Thanks for pushing this to master! But why not backpatch this?
Some of my coworkers use make installcheck extensively, and
have complained about the warnings. Those warnings could possibly
break some automated testing systems/scripts, but I haven't seen it.

And since PG16-17 will still be supported for a while, those warnings
will exist for this exact while :)

Also, to me the patch seems low-risk. Are such annoyances backpatched
often?

Regards, Oleg Tselebrovskiy