From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Windows UTF8 system locale |
Date: | 2024-12-16 19:27:26 |
Message-ID: | 20241216192726.a5.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2024-12-16 19:37:36 | Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit? |
Previous Message | Peter Geoghegan | 2024-12-16 19:17:41 | Re: Maybe we should reduce SKIP_PAGES_THRESHOLD a bit? |