Re: Windows UTF8 system locale - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Windows UTF8 system locale
Date
Msg-id 20241216192726.a5.nmisch@google.com
Whole thread Raw
In response to Windows UTF8 system locale  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Sun, Dec 15, 2024 at 06:43:35PM +0100, Michail Nikolaev wrote:
> I have Win 11 with that feature enabled, 200_connstr.pl passes without any
> issues, but 010_dump_connstr.pl fails, yes.
> All other tests seem to be passing, at least without ICU enabled.
> 
>  010_dump_connstr.pl log is attached.

Thanks.  I'll guess 200_connstr passed but created different names than
intended.  It likely got "will be truncated" messages like 010_dump_connstr
did.  Unlike 010_dump_connstr, nothing in 200_connstr fails if the resulting
object name doesn't match the intended name.

010_dump_connstr failed earlier than I hypothesized.  It failed when
pg_authid.rolname for $username4 got U+FFFD characters, which didn't match
what config_sspi_auth() wrote into pg_ident.conf.  CI w/ CP_UTF8 might evade
that particular failure via its use of PG_TEST_USE_UNIX_SOCKETS=1.

Reaching the hypothesized failure at the pg_dumpall->pg_dump call would need a
modified test.  These tests use the createdb executable.  Replacing a createdb
run with safe_psql() of a CREATE DATABASE command should reproduce the
pg_dumpall->pg_dump failure.



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?
Next
From: Peter Geoghegan
Date:
Subject: Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit?