010_database.pl fails on openbsd w/ LC_ALL=LANG=C
Hi,
I was rebasing my meson tree, which has more OSs added to CI, and noticed that
010_database.pl started failing on openbsd recently-ish, without the CI
environment for that having changed.
The tests passed on openbsd when my tree was based on 47b7051bc82
(2023-06-01), but failed after rebasing onto a798660ebe3 (2023-06-29).
Example of a failing run:
https://cirrus-ci.com/task/6391476419035136?logs=test_world#L273
https://api.cirrus-ci.com/v1/artifact/task/6391476419035136/testrun/build/testrun/icu/010_database/log/regress_log_010_database
https://api.cirrus-ci.com/v1/artifact/task/6391476419035136/testrun/build/testrun/icu/010_database/log/010_database_node1.log
[07:25:06.421](0.161s) not ok 6 - ICU-specific locale must be specified with ICU_LOCALE: exit code not 0
[07:25:06.423](0.002s) # Failed test 'ICU-specific locale must be specified with ICU_LOCALE: exit code not 0'
# at /home/postgres/postgres/src/test/icu/t/010_database.pl line 78.
[07:25:06.423](0.000s) # got: '0'
# expected: anything else
[07:25:06.424](0.001s) not ok 7 - ICU-specific locale must be specified with ICU_LOCALE: error message
[07:25:06.424](0.001s) # Failed test 'ICU-specific locale must be specified with ICU_LOCALE: error message'
# at /home/postgres/postgres/src/test/icu/t/010_database.pl line 80.
[07:25:06.424](0.000s) # 'psql:<stdin>:2: NOTICE: using standard form "und-u-ks-level1" for ICU locale "@colStrength=primary"'
# doesn't match '(?^:ERROR: invalid LC_COLLATE locale name)'
[07:25:06.425](0.000s) 1..7
The server log says:
2023-07-02 07:25:05.946 UTC [15605][client backend] [010_database.pl][3/14:0] LOG: statement: CREATE DATABASE dbicu1 LOCALE_PROVIDER icu LOCALE 'C' TEMPLATE template0 ENCODING UTF8
2023-07-02 07:25:05.947 UTC [15605][client backend] [010_database.pl][3/14:0] WARNING: could not convert locale name "C" to language tag: U_ILLEGAL_ARGUMENT_ERROR
2023-07-02 07:25:05.948 UTC [15605][client backend] [010_database.pl][3/14:0] WARNING: ICU locale "C" has unknown language "c"
2023-07-02 07:25:05.948 UTC [15605][client backend] [010_database.pl][3/14:0] HINT: To disable ICU locale validation, set parameter icu_validation_level to DISABLED.
Example of a succeeding run:
https://cirrus-ci.com/task/5893925412536320?logs=test_world#L261
I have not yet debugged this further.
Greetings,
Andres Freund
On Sun, 2023-07-02 at 09:56 -0700, Andres Freund wrote:
# expected: anything else
[07:25:06.424](0.001s) not ok 7 - ICU-specific locale must be
specified with ICU_LOCALE: error message
[07:25:06.424](0.001s) # Failed test 'ICU-specific locale must be
specified with ICU_LOCALE: error message'
# at /home/postgres/postgres/src/test/icu/t/010_database.pl line
80.
[07:25:06.424](0.000s) # 'psql:<stdin>:2: NOTICE:
using standard form "und-u-ks-level1" for ICU locale
"@colStrength=primary"'
# doesn't match '(?^:ERROR: invalid LC_COLLATE locale name)'
[07:25:06.425](0.000s) 1..7
[I apologize for the delay.]
The test is assuming that locale "@colStrength=primary" is valid for
ICU but invalid for libc. It seems that on that platform, setlocale()
is accepting it?
If some libc implementations are too permissive, I might need to just
disable this test. But if we can find a locale that is consistently
acceptable in ICU but invalid in libc, then I can keep it... perhaps
"und@colStrength=primary"?
Regards,
Jeff Davis
On Sat, Jul 8, 2023 at 3:52 AM Jeff Davis <pgsql@j-davis.com> wrote:
The test is assuming that locale "@colStrength=primary" is valid for
ICU but invalid for libc. It seems that on that platform, setlocale()
is accepting it?If some libc implementations are too permissive, I might need to just
disable this test. But if we can find a locale that is consistently
acceptable in ICU but invalid in libc, then I can keep it... perhaps
"und@colStrength=primary"?
Doesn't look too hopeful: https://man.openbsd.org/setlocale.3
On Sat, 2023-07-08 at 07:04 +1200, Thomas Munro wrote:
Doesn't look too hopeful: https://man.openbsd.org/setlocale.3
Hmm. I could try using a bogus encoding, but that may be too clever.
I'll just remove the test.
Regards,
Jeff Davis