Thread: pgsql: Fix createdb tests for C locale
Fix createdb tests for C locale If the createdb tests run under the C locale, the database cluster will be initialized with encoding SQL_ASCII. With the checks added in c7db01e325a530ec38ec7ba57cd3ed32e123e33c, this will cause several ICU-related tests to fail because SQL_ASCII is not supported by ICU. To work around that, use initdb option -E UTF8 for those tests to get past that check. Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8135d0bd455217bd345090bae085b2bbcf62bdb0 Modified Files -------------- src/bin/scripts/t/020_createdb.pl | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)
Re: Peter Eisentraut > Fix createdb tests for C locale > > If the createdb tests run under the C locale, the database cluster > will be initialized with encoding SQL_ASCII. With the checks added in > c7db01e325a530ec38ec7ba57cd3ed32e123e33c, this will cause several > ICU-related tests to fail because SQL_ASCII is not supported by ICU. > To work around that, use initdb option -E UTF8 for those tests to get > past that check. This seems to have broken 15 on apt.pg.o/Debian: 00:49:04 make[2]: Leaving directory '/<<PKGBUILDDIR>>/build/src/test/subscription' 00:49:04 make -C icu check 00:49:04 make[2]: Entering directory '/<<PKGBUILDDIR>>/build/src/test/icu' 00:49:04 echo "+++ tap check in src/test/icu +++" && rm -rf '/<<PKGBUILDDIR>>/build/src/test/icu'/tmp_check && /bin/mkdir-p '/<<PKGBUILDDIR>>/build/src/test/icu'/tmp_check && cd /<<PKGBUILDDIR>>/build/../src/test/icu && TESTDIR='/<<PKGBUILDDIR>>/build/src/test/icu' PATH="/<<PKGBUILDDIR>>/build/tmp_install/usr/lib/postgresql/15/bin:/<<PKGBUILDDIR>>/build/src/test/icu:$PATH" LD_LIBRARY_PATH="/<<PKGBUILDDIR>>/build/tmp_install/usr/lib/x86_64-linux-gnu" PGPORT='65432' PG_REGRESS='/<<PKGBUILDDIR>>/build/src/test/icu/../../../src/test/regress/pg_regress'/usr/bin/prove -I /<<PKGBUILDDIR>>/build/../src/test/perl/-I /<<PKGBUILDDIR>>/build/../src/test/icu --verbose t/*.pl 00:49:04 +++ tap check in src/test/icu +++ 00:49:06 00:49:06 # Failed test 'ICU locale must be specified for ICU provider: error message' 00:49:06 # at t/010_database.pl line 60. 00:49:06 # 'psql:<stdin>:1: ERROR: encoding "SQL_ASCII" is not supported with ICU provider' 00:49:06 # doesn't match '(?^:ERROR: ICU locale must be specified)' 00:49:06 # Looks like you failed 1 test of 5. 00:49:06 t/010_database.pl .. 00:49:06 ok 1 - sort by database default locale 00:49:06 ok 2 - sort by explicit collation standard 00:49:06 ok 3 - sort by explicit collation upper first 00:49:06 ok 4 - ICU locale must be specified for ICU provider: exit code not 0 00:49:06 not ok 5 - ICU locale must be specified for ICU provider: error message 00:49:06 1..5 00:49:06 Dubious, test returned 1 (wstat 256, 0x100) 00:49:06 Failed 1/5 subtests 00:49:06 00:49:06 Test Summary Report 00:49:06 ------------------- 00:49:06 t/010_database.pl (Wstat: 256 Tests: 5 Failed: 1) 00:49:06 Failed test: 5 00:49:06 Non-zero exit status: 1 00:49:06 Files=1, Tests=5, 2 wallclock secs ( 0.02 usr 0.00 sys + 0.81 cusr 0.32 csys = 1.15 CPU) 00:49:06 Result: FAIL 00:49:06 make[2]: *** [Makefile:19: check] Error 1 00:49:06 make[2]: Leaving directory '/<<PKGBUILDDIR>>/build/src/test/icu' https://pgdgbuild.dus.dg-i.net/job/postgresql-15-binaries-snapshot/194/architecture=amd64,distribution=sid/console Christoph
Christoph Berg <myon@debian.org> writes:
> This seems to have broken 15 on apt.pg.o/Debian:
Fails on RHEL8 too, if LANG=C.
OK if LANG=C.utf8.
(The lack of buildfarm complaints is distressing. Apparently
our coverage of ICU is very thin.)
regards, tom lane
On 17.09.22 12:15, Christoph Berg wrote: > Re: Peter Eisentraut >> Fix createdb tests for C locale >> >> If the createdb tests run under the C locale, the database cluster >> will be initialized with encoding SQL_ASCII. With the checks added in >> c7db01e325a530ec38ec7ba57cd3ed32e123e33c, this will cause several >> ICU-related tests to fail because SQL_ASCII is not supported by ICU. >> To work around that, use initdb option -E UTF8 for those tests to get >> past that check. > > This seems to have broken 15 on apt.pg.o/Debian: fixed
On 17.09.22 16:44, Tom Lane wrote: > Christoph Berg <myon@debian.org> writes: >> This seems to have broken 15 on apt.pg.o/Debian: > > Fails on RHEL8 too, if LANG=C. > OK if LANG=C.utf8. > > (The lack of buildfarm complaints is distressing. Apparently > our coverage of ICU is very thin.) This issue is with a combination of ICU and environment locale "C". There is ICU coverage in the build farm, but apparently none with C locale set.
Hi, On 2022-09-19 15:46:04 -0400, Peter Eisentraut wrote: > On 17.09.22 16:44, Tom Lane wrote: > > Christoph Berg <myon@debian.org> writes: > > > This seems to have broken 15 on apt.pg.o/Debian: > > > > Fails on RHEL8 too, if LANG=C. > > OK if LANG=C.utf8. > > > > (The lack of buildfarm complaints is distressing. Apparently > > our coverage of ICU is very thin.) > > This issue is with a combination of ICU and environment locale "C". There is > ICU coverage in the build farm, but apparently none with C locale set. I could change the configuration of mylodon (Werror=cXX-extensions), serinus (gcc snapshots) or calliphoridae (DDCOPY_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST ) to use LANG=C. I don't think it'd affect the aspects they're otherwise testing. Greetings, Andres Freund
On 2022-09-19 Mo 15:46, Peter Eisentraut wrote: > On 17.09.22 16:44, Tom Lane wrote: >> Christoph Berg <myon@debian.org> writes: >>> This seems to have broken 15 on apt.pg.o/Debian: >> >> Fails on RHEL8 too, if LANG=C. >> OK if LANG=C.utf8. >> >> (The lack of buildfarm complaints is distressing. Apparently >> our coverage of ICU is very thin.) > > This issue is with a combination of ICU and environment locale "C". > There is ICU coverage in the build farm, but apparently none with C > locale set. > > Yep, it's been like that for 5 years, ever since we added support for the ICU collation test. See <https://github.com/PGBuildFarm/client-code/blob/main/PGBuild/Modules/TestICU.pm> line 59: return unless $locale =~ /utf8/i; We can change that of course, I'm open to suggestions. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com