pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18711: Attempting a connection with a database name longer than 63 characters now fails
67+ messages / 7 participants
[nested] [flat]
Commits from this thread:
2024-12-12 a0ff56e2d3 d09fbf645e Revert "Don't truncate database and user names in startup packets."
* BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
@ 2024-11-16 00:12 PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: PG Bug reporting form @ 2024-11-16 00:12 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: adam@labkey.com
The following bug has been logged on the website:
Bug reference: 18711
Logged by: Adam Rauch
Email address: adam@labkey.com
PostgreSQL version: 17.1
Operating system: Windows 11
Description:
For many years, our test infrastructure has used database names that are
longer than the stated maximum length of 63 characters. The PostgreSQL
server simply truncates these names to 63 characters in all operations and
everything works fine. Starting with 17.x, our application is able to CREATE
and ALTER databases with long names, but all connection attempts using them
fail with an error: database "<very long name>" does not exist
I fully recognize that these names are not legal, the previous truncation
behavior was not documented, and there are obvious ways to work around this
"issue." But given the long running truncation behavior, the now
inconsistent behavior (CREATE and ALTER happily accept long database names,
but connections fail), and the lack of any mention in the release notes
makes me think this may be an unintentional change worth flagging.
I happen to be connecting via the (latest) JDBC driver. I can provide the
simple Java code that passes on PostgreSQL 16 but fails on PostgreSQL 17, if
needed.
Thanks!
Adam
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
@ 2024-11-17 18:00 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-17 18:00 UTC (permalink / raw)
To: adam@labkey.com; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> For many years, our test infrastructure has used database names that are
> longer than the stated maximum length of 63 characters. The PostgreSQL
> server simply truncates these names to 63 characters in all operations and
> everything works fine. Starting with 17.x, our application is able to CREATE
> and ALTER databases with long names, but all connection attempts using them
> fail with an error: database "<very long name>" does not exist
Yeah, this was an intentional change in v17:
commit 562bee0fc13dc95710b8db6a48edad2f3d052f2e
Author: Nathan Bossart <nathan@postgresql.org>
Date: Mon Jul 3 13:18:05 2023 -0700
Don't truncate database and user names in startup packets.
Unlike commands such as CREATE DATABASE, ProcessStartupPacket()
does not perform multibyte-aware truncation of overlength names.
This means that connection attempts might fail even if the user
provides the same overlength names that were used in CREATE
DATABASE, CREATE ROLE, etc. Ideally, we'd do the same multibyte-
aware truncation in both code paths, but it doesn't seem worth the
added complexity of trying to discover the encoding of the names.
Instead, let's simply skip truncating the names in the startup
packet and let the user/database lookup fail later on. With this
change, users must provide the exact names stored in the catalogs,
even if the names were truncated.
This reverts commit d18c1d1f51.
Author: Bertrand Drouvot
Reviewed-by: Kyotaro Horiguchi, Tom Lane
Discussion: https://postgr.es/m/07436793-1426-29b2-f924-db7422a05fb7%40gmail.com
As said, the difficulty is that we don't know what encoding the
incoming name is meant to be in, and with multibyte encodings that
matters. The name actually stored in the catalog might be less
than 63 bytes long if it was truncated in a multibyte-aware way,
so that the former behavior of blindly truncating at 63 bytes
can still yield unexpected no-such-database results.
I can imagine still performing the truncation if the incoming
name is all-ASCII, but that seems like a hack. The world isn't
nearly as ASCII-centric as it was in 2001.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-19 18:48 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-19 18:48 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
On Sun, Nov 17, 2024 at 01:00:14PM -0500, Tom Lane wrote:
> As said, the difficulty is that we don't know what encoding the
> incoming name is meant to be in, and with multibyte encodings that
> matters. The name actually stored in the catalog might be less
> than 63 bytes long if it was truncated in a multibyte-aware way,
> so that the former behavior of blindly truncating at 63 bytes
> can still yield unexpected no-such-database results.
>
> I can imagine still performing the truncation if the incoming
> name is all-ASCII, but that seems like a hack. The world isn't
> nearly as ASCII-centric as it was in 2001.
I wonder if we should consider removing the identifier truncation
altogether. Granted, it mostly works (or at least did before v17), but I'm
not sure we'd make the same decision today if we were starting from
scratch. IMHO it'd be better to ERROR so that users are forced to produce
legal identifiers. That being said, I realize this behavior has been
present for over a quarter century now [0] [1] [2], and folks are unlikely
to be happy with even more breakage.
[0] https://postgr.es/c/d15c37c
[1] https://postgr.es/c/0672a3c
[2] https://postgr.es/c/49581f9
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-19 19:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-19 19:33 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Sun, Nov 17, 2024 at 01:00:14PM -0500, Tom Lane wrote:
>> As said, the difficulty is that we don't know what encoding the
>> incoming name is meant to be in, and with multibyte encodings that
>> matters. The name actually stored in the catalog might be less
>> than 63 bytes long if it was truncated in a multibyte-aware way,
>> so that the former behavior of blindly truncating at 63 bytes
>> can still yield unexpected no-such-database results.
> I wonder if we should consider removing the identifier truncation
> altogether. Granted, it mostly works (or at least did before v17), but I'm
> not sure we'd make the same decision today if we were starting from
> scratch. IMHO it'd be better to ERROR so that users are forced to produce
> legal identifiers. That being said, I realize this behavior has been
> present for over a quarter century now [0] [1] [2], and folks are unlikely
> to be happy with even more breakage.
Yeah, I think removing it now is a non-starter.
I did think of a way that we could approximate encoding-correct
truncation here, relying on the fact that what's in pg_database
is encoding-correct according to somebody:
1. If NAMEDATALEN-1'th byte is ASCII (high bit clear), just truncate
there and look up as usual.
2. If it's non-ASCII, truncate there and try to look up. On success,
we're good. On failure, if the next-to-last byte is non-ASCII,
truncate that too and try to look up. Repeat a maximum of
MAX_MULTIBYTE_CHAR_LEN-1 times before failing.
I think this works unconditionally so long as all entries in
pg_database.datname are in the same encoding. If there's a
mixture of encodings (which we don't forbid) then in principle
you could probably select a database other than the one the
client thought it was asking for. But that seems mighty
improbable, and the answer can always be "so connect using
the name as it appears in the catalog".
It's ugly of course. But considering that we got a complaint
so quickly after v17 release, I'm not sure we can just camp on
562bee0fc as being an acceptable answer.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-19 22:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-19 22:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
On Tue, Nov 19, 2024 at 02:33:27PM -0500, Tom Lane wrote:
> I did think of a way that we could approximate encoding-correct
> truncation here, relying on the fact that what's in pg_database
> is encoding-correct according to somebody:
>
> 1. If NAMEDATALEN-1'th byte is ASCII (high bit clear), just truncate
> there and look up as usual.
>
> 2. If it's non-ASCII, truncate there and try to look up. On success,
> we're good. On failure, if the next-to-last byte is non-ASCII,
> truncate that too and try to look up. Repeat a maximum of
> MAX_MULTIBYTE_CHAR_LEN-1 times before failing.
>
> I think this works unconditionally so long as all entries in
> pg_database.datname are in the same encoding. If there's a
> mixture of encodings (which we don't forbid) then in principle
> you could probably select a database other than the one the
> client thought it was asking for. But that seems mighty
> improbable, and the answer can always be "so connect using
> the name as it appears in the catalog".
That's an interesting idea. That code would probably need to live in
GetDatabaseTuple(), but it seems doable. We might be able to avoid the
"mighty improbable" case by always truncating up to
MAX_MULTIBYTE_CHAR_LEN-1 times and failing if there are multiple matches,
too.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-19 23:09 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 08:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 2 replies; 67+ messages in thread
From: Tom Lane @ 2024-11-19 23:09 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Tue, Nov 19, 2024 at 02:33:27PM -0500, Tom Lane wrote:
>> I did think of a way that we could approximate encoding-correct
>> truncation here, relying on the fact that what's in pg_database
>> is encoding-correct according to somebody:
>> ...
> That's an interesting idea. That code would probably need to live in
> GetDatabaseTuple(), but it seems doable. We might be able to avoid the
> "mighty improbable" case by always truncating up to
> MAX_MULTIBYTE_CHAR_LEN-1 times and failing if there are multiple matches,
> too.
Hmm ... but with short characters (e.g. LATIN1) there might be
legitimately-different names that that rule would complain about.
Still, the workaround remains "so spell it like it is in the catalog".
On balance I think that's an improvement over what I was visualizing.
Also, we could bypass the multiple lookups unless both the
NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII, which
should be rare enough to make it not much of a performance issue.
One annoying point is that we also need this for role lookup.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-20 03:47 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-20 03:47 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
On Tue, Nov 19, 2024 at 06:09:44PM -0500, Tom Lane wrote:
> Also, we could bypass the multiple lookups unless both the
> NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII, which
> should be rare enough to make it not much of a performance issue.
I'm admittedly not an expert in the multi-byte code, but since there are
encodings like LATIN1 that use a byte per character, don't we need to do
multiple lookups any time the NAMEDATALEN-1'th byte is non-ASCII?
> One annoying point is that we also need this for role lookup.
Right.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-20 04:23 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-20 04:23 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Tue, Nov 19, 2024 at 06:09:44PM -0500, Tom Lane wrote:
>> Also, we could bypass the multiple lookups unless both the
>> NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII, which
>> should be rare enough to make it not much of a performance issue.
> I'm admittedly not an expert in the multi-byte code, but since there are
> encodings like LATIN1 that use a byte per character, don't we need to do
> multiple lookups any time the NAMEDATALEN-1'th byte is non-ASCII?
I don't think so, but maybe I'm missing something. An important
property of backend-legal encodings is that all bytes of a multibyte
character have their high bits set. Thus if the NAMEDATALEN-2'th
byte does not have that, it is not part of a multibyte character.
That's also the reason we can stop if we reach a high-bit-clear
byte while backing up to earlier bytes.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-20 15:35 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-20 15:35 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
On Tue, Nov 19, 2024 at 11:23:13PM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> I'm admittedly not an expert in the multi-byte code, but since there are
>> encodings like LATIN1 that use a byte per character, don't we need to do
>> multiple lookups any time the NAMEDATALEN-1'th byte is non-ASCII?
>
> I don't think so, but maybe I'm missing something. An important
> property of backend-legal encodings is that all bytes of a multibyte
> character have their high bits set. Thus if the NAMEDATALEN-2'th
> byte does not have that, it is not part of a multibyte character.
> That's also the reason we can stop if we reach a high-bit-clear
> byte while backing up to earlier bytes.
That's good to know. If we can assume that 1) all bytes of a multibyte
character have the high bit set and 2) all multibyte characters actually
require multiple bytes, then there are just a handful of cases that require
multiple lookups, and we can restrict even those to some extent, too.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-20 15:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-20 15:54 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> That's good to know. If we can assume that 1) all bytes of a multibyte
> character have the high bit set and 2) all multibyte characters actually
> require multiple bytes, then there are just a handful of cases that require
> multiple lookups, and we can restrict even those to some extent, too.
I'm failing to parse your (2). Either that's content-free or you're
thinking something that probably isn't true. There are encodings
(mostly the LATINn series) that have high-bit-set characters that
only occupy one byte. So I don't think we can take any shortcuts
compared to the strip-one-byte-at-a-time approach.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-20 16:02 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-20 16:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
On Wed, Nov 20, 2024 at 10:54:50AM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> That's good to know. If we can assume that 1) all bytes of a multibyte
>> character have the high bit set and 2) all multibyte characters actually
>> require multiple bytes, then there are just a handful of cases that require
>> multiple lookups, and we can restrict even those to some extent, too.
>
> I'm failing to parse your (2). Either that's content-free or you're
> thinking something that probably isn't true. There are encodings
> (mostly the LATINn series) that have high-bit-set characters that
> only occupy one byte. So I don't think we can take any shortcuts
> compared to the strip-one-byte-at-a-time approach.
I'm probably missing something here, sorry.
Upthread, you mentioned that we could bypass multiple lookups unless both
the NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII. But if
there are encodings with the high bit set that don't require multiple bytes
per character, then how can we do that? For example, let's say the
initially-truncated identifier ends with an ASCII byte followed by a
non-ASCII byte. That last byte might be a LATIN1 character, or it could be
the beginning of a character that requires multiple bytes, so we need to
lookup both the initially truncated string as well as the string with one
extra byte truncated, right?
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-20 16:29 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-20 16:29 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> Upthread, you mentioned that we could bypass multiple lookups unless both
> the NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII. But if
> there are encodings with the high bit set that don't require multiple bytes
> per character, then how can we do that?
Well, we don't know the length of the hypothetically-truncated
character, but if there was one then all its bytes must have had their
high bits set. Suppose that the untruncated name has a 4-byte
multibyte character extending from the NAMEDATALEN-3 byte through the
NAMEDATALEN'th byte (counting in origin zero here):
...61 irrelevant bytes... C1 C2 C3 C4 ...
The original CREATE DATABASE would have removed that whole character
and stored a name of length NAMEDATALEN-3:
...61 irrelevant bytes...
In the connection attempt, when we
receive the untruncated name, we'll first try to truncate it to
NAMEDATALEN-1 bytes:
...61 irrelevant bytes... C1 C2
We'll look that up and not find it. At this point we remember that
C3 had the high bit set, and we note that C2 does too, so we try
...61 irrelevant bytes... C1
That still doesn't work, but C1 still has the high bit set,
so we try
...61 irrelevant bytes...
and find the match.
Now as for the shortcut cases: if C3 does not have the high bit set,
it cannot be part of a multibyte character. Therefore the original
encoding-aware truncation would have removed C3 and following bytes,
but no more. The character immediately before might have been one
byte or several, but it doesn't matter. Similarly, if C2 does not
have the high bit set, it cannot be part of a multibyte character.
The original truncation would have removed C3 and following bytes,
but no more.
Another way to think about this is that without knowledge of the
encoding, we don't know whether a run of several high-bit-set
bytes represents one character or several. But all the encodings
we support are ASCII extensions, meaning that any high-bit-clear
byte represents an ASCII character and is not part of a multibyte
character. So it would have gotten truncated or not independently
of what's around it.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-20 16:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-20 16:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
On Wed, Nov 20, 2024 at 11:29:56AM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> Upthread, you mentioned that we could bypass multiple lookups unless both
>> the NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII. But if
>> there are encodings with the high bit set that don't require multiple bytes
>> per character, then how can we do that?
>
> Well, we don't know the length of the hypothetically-truncated
> character, but if there was one then all its bytes must have had their
> high bits set. Suppose that the untruncated name has a 4-byte
> multibyte character extending from the NAMEDATALEN-3 byte through the
> NAMEDATALEN'th byte (counting in origin zero here):
>
> [...]
>
> Now as for the shortcut cases: if C3 does not have the high bit set,
> it cannot be part of a multibyte character. Therefore the original
> encoding-aware truncation would have removed C3 and following bytes,
> but no more. The character immediately before might have been one
> byte or several, but it doesn't matter. Similarly, if C2 does not
> have the high bit set, it cannot be part of a multibyte character.
> The original truncation would have removed C3 and following bytes,
> but no more.
Oh, I think I had an off-by-one error in my mental model and was thinking
of the NAMEDATALEN-1'th byte as the last possible byte in the identifier
(i.e., name[NAMEDATALEN - 2]), whereas you meant the location where the
trailing zero would go for the largest possible all-ASCII identifier (i.e.,
name[NAMEDATALEN - 1]). Thank you for elaborating.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-20 22:36 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-20 22:36 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: adam@labkey.com, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; pgsql-bugs@lists.postgresql.org
Here is a draft patch that seems to work with some simple tests. I've yet
to look into the role name side of things.
--
nathan
Attachments:
v1-0001-attempt-multibyte-aware-truncation-of-database-na.patch (text/plain, 0B) download
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-21 07:27 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-22 04:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails John Naylor <johncnaylorls@gmail.com>
0 siblings, 2 replies; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-21 07:27 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Wed, Nov 20, 2024 at 04:36:44PM -0600, Nathan Bossart wrote:
> Here is a draft patch that seems to work with some simple tests.
Thanks!
While doing the review, I added comments (that also helped me understand the
code). So please find attached, v2 which is v1 with added comments. The logic
in v1 looks good to me. The comments are based on my understanding so could
be wrong.
+ /* XXX: should we fix process title? */
Prior to 562bee0fc1, we would have seen the truncated name in the process title.
Now, with the patch applied, we would see the non truncated name (even in the
non multibyte case).
So, if want to be at the same state as prior to 562bee0fc1, then yes we would
need to fix the process title. But thinking about it, I think that's a good thing
to see what the "initial" attempt was (specially as the code is much more
complicated now), so there is pros showing the non truncated name too.
I'm tempted to vote for "show the non truncated name" then.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachments:
v2-0001-attempt-multibyte-aware-truncation-of-database-na.patch (text/x-diff, 0B) download
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-21 14:21 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
1 sibling, 1 reply; 67+ messages in thread
From: Bruce Momjian @ 2024-11-21 14:21 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 07:27:22AM +0000, Bertrand Drouvot wrote:
> + /*
> + * If the original name is too long and we see two consecutive bytes
> + * with their high bits set at the truncation point, we might have
> + * truncated in the middle of a multibyte character. In multibyte
> + * encodings, every byte of a multibyte character has its high bit
> + * set. So if IS_HIGHBIT_SET is true for both NAMEDATALEN-1 and
> + * NAMEDATALEN-2, we know we're in the middle of a multibyte
> + * character. We need to try truncating one more byte back to find the
> + * start of the next character.
> + */
...
> + /*
> + * If we've hit a byte with high bit clear (an ASCII byte), we
> + * know we can't be in the middle of a multibyte character,
> + * because all bytes of a multibyte character must have their
> + * high bits set. Any following byte must therefore be the
> + * start of a new character, so we can stop looking for
> + * earlier truncation points.
> + */
I don't understand this logic. Why are two bytes important? If we knew
it was UTF8 we could check for non-first bytes always starting with
bits 10, but we can't know that.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
@ 2024-11-21 14:35 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-21 14:35 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Thu, Nov 21, 2024 at 09:21:16AM -0500, Bruce Momjian wrote:
> On Thu, Nov 21, 2024 at 07:27:22AM +0000, Bertrand Drouvot wrote:
> > + /*
> > + * If the original name is too long and we see two consecutive bytes
> > + * with their high bits set at the truncation point, we might have
> > + * truncated in the middle of a multibyte character. In multibyte
> > + * encodings, every byte of a multibyte character has its high bit
> > + * set. So if IS_HIGHBIT_SET is true for both NAMEDATALEN-1 and
> > + * NAMEDATALEN-2, we know we're in the middle of a multibyte
> > + * character. We need to try truncating one more byte back to find the
> > + * start of the next character.
> > + */
> ...
> > + /*
> > + * If we've hit a byte with high bit clear (an ASCII byte), we
> > + * know we can't be in the middle of a multibyte character,
> > + * because all bytes of a multibyte character must have their
> > + * high bits set. Any following byte must therefore be the
> > + * start of a new character, so we can stop looking for
> > + * earlier truncation points.
> > + */
>
> I don't understand this logic. Why are two bytes important? If we knew
> it was UTF8 we could check for non-first bytes always starting with
> bits 10, but we can't know that.
I think this is because this is a reliable way to detect if the truncation happened
in the middle of a character, without needing to know the specifics of the encoding.
My understanding is that the key insight is that in any multibyte encoding, all
bytes within a multibyte character will have their high bits set.
That's just my understanding from the code and Tom's previous explanations: I
might be wrong as not an expert in this area.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-21 14:47 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 00:11 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 67+ messages in thread
From: Bruce Momjian @ 2024-11-21 14:47 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 02:35:50PM +0000, Bertrand Drouvot wrote:
> On Thu, Nov 21, 2024 at 09:21:16AM -0500, Bruce Momjian wrote:
> > I don't understand this logic. Why are two bytes important? If we knew
> > it was UTF8 we could check for non-first bytes always starting with
> > bits 10, but we can't know that.
>
> I think this is because this is a reliable way to detect if the truncation happened
> in the middle of a character, without needing to know the specifics of the encoding.
>
> My understanding is that the key insight is that in any multibyte encoding, all
> bytes within a multibyte character will have their high bits set.
>
> That's just my understanding from the code and Tom's previous explanations: I
> might be wrong as not an expert in this area.
But the logic doesn't make sense. Why would two bytes be any different
than one? I assumed you would just remove all trailing high-bit bytes
and stop and the first non-high-bit byte. Also, do we really expect
there to be trailing multi-byte characters and then some ASCII before
it? Isn't it likely it will be all ASCII or all multi-byte characters?
I guess for Latin1, it would work fine, but I assume for Asian
languages, it will be almost all multi-byte characters. I guess digits
would be ASCII. This all just seems very unfocused.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
@ 2024-11-21 15:14 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-21 15:14 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 09:47:56AM -0500, Bruce Momjian wrote:
> On Thu, Nov 21, 2024 at 02:35:50PM +0000, Bertrand Drouvot wrote:
>> On Thu, Nov 21, 2024 at 09:21:16AM -0500, Bruce Momjian wrote:
>> > I don't understand this logic. Why are two bytes important? If we knew
>> > it was UTF8 we could check for non-first bytes always starting with
>> > bits 10, but we can't know that.
>>
>> I think this is because this is a reliable way to detect if the truncation happened
>> in the middle of a character, without needing to know the specifics of the encoding.
>>
>> My understanding is that the key insight is that in any multibyte encoding, all
>> bytes within a multibyte character will have their high bits set.
>>
>> That's just my understanding from the code and Tom's previous explanations: I
>> might be wrong as not an expert in this area.
>
> But the logic doesn't make sense. Why would two bytes be any different
> than one?
Tom provided a concise explanation upthread [0]. My understanding is the
same as Bertrand's, i.e., this is an easy way to rule out a bunch of cases
where we know that we couldn't possibly have truncated in the middle of a
multi-byte character. This allows us to avoid doing multiple pg_database
lookups.
> I assumed you would just remove all trailing high-bit bytes
> and stop and the first non-high-bit byte.
I think this risks truncating more than one multi-byte character, which
would cause the login path to truncate differently than the CREATE/ALTER
DATABASE path (which is encoding-aware).
> Also, do we really expect
> there to be trailing multi-byte characters and then some ASCII before
> it? Isn't it likely it will be all ASCII or all multi-byte characters?
> I guess for Latin1, it would work fine, but I assume for Asian
> languages, it will be almost all multi-byte characters. I guess digits
> would be ASCII.
All of these seem within the realm of possibility to me.
> This all just seems very unfocused.
I see the following options:
* Try to do multibyte-aware truncation (the patch at hand).
* Only truncate for all-ASCII identifiers for historical purposes. Folks
using non-ASCII characters in database names will need to specify the
datname exactly during login.
* ERROR for long identifiers instead of automatically truncating (upthread
this was considered a non-starter since this behavior has been around for
so long).
* Revert the patch, leaving multibyte database names potentially broken
(AFAIK Bertrand's initial report is the only one).
* Do nothing, so folks who previously relied on the truncation will now
have to specify the datname exactly during login as of >= v17.
[0] https://postgr.es/m/158506.1732120196%40sss.pgh.pa.us
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-21 16:44 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Bruce Momjian @ 2024-11-21 16:44 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 09:14:23AM -0600, Nathan Bossart wrote:
> On Thu, Nov 21, 2024 at 09:47:56AM -0500, Bruce Momjian wrote:
> > On Thu, Nov 21, 2024 at 02:35:50PM +0000, Bertrand Drouvot wrote:
> >> On Thu, Nov 21, 2024 at 09:21:16AM -0500, Bruce Momjian wrote:
> >> > I don't understand this logic. Why are two bytes important? If we knew
> >> > it was UTF8 we could check for non-first bytes always starting with
> >> > bits 10, but we can't know that.
> >>
> >> I think this is because this is a reliable way to detect if the truncation happened
> >> in the middle of a character, without needing to know the specifics of the encoding.
> >>
> >> My understanding is that the key insight is that in any multibyte encoding, all
> >> bytes within a multibyte character will have their high bits set.
> >>
> >> That's just my understanding from the code and Tom's previous explanations: I
> >> might be wrong as not an expert in this area.
> >
> > But the logic doesn't make sense. Why would two bytes be any different
> > than one?
>
> Tom provided a concise explanation upthread [0]. My understanding is the
> same as Bertrand's, i.e., this is an easy way to rule out a bunch of cases
> where we know that we couldn't possibly have truncated in the middle of a
> multi-byte character. This allows us to avoid doing multiple pg_database
> lookups.
Where does Tom mention anything about checking two bytes? He is
basically saying remove all trailing high-bit characters until you get a
match, because once you get a match, you are have found the point of
valid truncation for the encoding. In fact, here, he specifically talks
about MAX_MULTIBYTE_CHAR_LEN-1:
https://www.postgresql.org/message-id/3796535.1732044807%40sss.pgh.pa.us
This text:
* If the original name is too long and we see two consecutive bytes
* with their high bits set at the truncation point, we might have
* truncated in the middle of a multibyte character. In multibyte
* encodings, every byte of a multibyte character has its high bit
* set. So if IS_HIGHBIT_SET is true for both NAMEDATALEN-1 and
* NAMEDATALEN-2, we know we're in the middle of a multibyte
* character. We need to try truncating one more byte back to find the
* start of the next character.
needs to be fixed, at a minimum, specifically, "So if IS_HIGHBIT_SET is
true for both NAMEDATALEN-1 and NAMEDATALEN-2, we know we're in the
middle of a multibyte character."
> > I assumed you would just remove all trailing high-bit bytes
> > and stop and the first non-high-bit byte.
>
> I think this risks truncating more than one multi-byte character, which
> would cause the login path to truncate differently than the CREATE/ALTER
> DATABASE path (which is encoding-aware).
True, we can stop at MAX_MULTIBYTE_CHAR_LEN-1, and know there is no match.
> * Try to do multibyte-aware truncation (the patch at hand).
Yes, I am fine with that, but we need to do more than the patch does to
accomplish this, unless I am totally confused.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
@ 2024-11-21 17:09 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-21 17:09 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 11:44:44AM -0500, Bruce Momjian wrote:
> On Thu, Nov 21, 2024 at 09:14:23AM -0600, Nathan Bossart wrote:
>> Tom provided a concise explanation upthread [0]. My understanding is the
>> same as Bertrand's, i.e., this is an easy way to rule out a bunch of cases
>> where we know that we couldn't possibly have truncated in the middle of a
>> multi-byte character. This allows us to avoid doing multiple pg_database
>> lookups.
>
> Where does Tom mention anything about checking two bytes?
Here [0]. And he further elaborated on this idea here [1].
> He is
> basically saying remove all trailing high-bit characters until you get a
> match, because once you get a match, you are have found the point of
> valid truncation for the encoding.
Yes, we still need to do that if it's possible the truncation wiped out
part of a multi-byte character. But it's not possible that we truncated
part of a multi-byte character if the NAMEDATALEN-1'th or NAMEDATALEN-2'th
byte is ASCII, in which case we can avoid doing extra lookups.
> This text:
>
> * If the original name is too long and we see two consecutive bytes
> * with their high bits set at the truncation point, we might have
> * truncated in the middle of a multibyte character. In multibyte
> * encodings, every byte of a multibyte character has its high bit
> * set. So if IS_HIGHBIT_SET is true for both NAMEDATALEN-1 and
> * NAMEDATALEN-2, we know we're in the middle of a multibyte
> * character. We need to try truncating one more byte back to find the
> * start of the next character.
>
> needs to be fixed, at a minimum, specifically, "So if IS_HIGHBIT_SET is
> true for both NAMEDATALEN-1 and NAMEDATALEN-2, we know we're in the
> middle of a multibyte character."
Agreed, the second-to-last sentence should be adjusted to something like
"we might be in the middle of a multibyte character." We don't know for
sure.
>> * Try to do multibyte-aware truncation (the patch at hand).
>
> Yes, I am fine with that, but we need to do more than the patch does to
> accomplish this, unless I am totally confused.
What more do you think is required?
[0] https://postgr.es/m/3976665.1732057784%40sss.pgh.pa.us
[1] https://postgr.es/m/158506.1732120196%40sss.pgh.pa.us
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-21 18:05 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Bruce Momjian @ 2024-11-21 18:05 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 11:09:14AM -0600, Nathan Bossart wrote:
> On Thu, Nov 21, 2024 at 11:44:44AM -0500, Bruce Momjian wrote:
> > On Thu, Nov 21, 2024 at 09:14:23AM -0600, Nathan Bossart wrote:
> >> Tom provided a concise explanation upthread [0]. My understanding is the
> >> same as Bertrand's, i.e., this is an easy way to rule out a bunch of cases
> >> where we know that we couldn't possibly have truncated in the middle of a
> >> multi-byte character. This allows us to avoid doing multiple pg_database
> >> lookups.
> >
> > Where does Tom mention anything about checking two bytes?
>
> Here [0]. And he further elaborated on this idea here [1].
>
> > He is
> > basically saying remove all trailing high-bit characters until you get a
> > match, because once you get a match, you are have found the point of
> > valid truncation for the encoding.
>
> Yes, we still need to do that if it's possible the truncation wiped out
> part of a multi-byte character. But it's not possible that we truncated
> part of a multi-byte character if the NAMEDATALEN-1'th or NAMEDATALEN-2'th
> byte is ASCII, in which case we can avoid doing extra lookups.
Why would you check for two characters at the end rather than just a
normal check in the main loop?
> > needs to be fixed, at a minimum, specifically, "So if IS_HIGHBIT_SET is
> > true for both NAMEDATALEN-1 and NAMEDATALEN-2, we know we're in the
> > middle of a multibyte character."
>
> Agreed, the second-to-last sentence should be adjusted to something like
> "we might be in the middle of a multibyte character." We don't know for
> sure.
>
> >> * Try to do multibyte-aware truncation (the patch at hand).
> >
> > Yes, I am fine with that, but we need to do more than the patch does to
> > accomplish this, unless I am totally confused.
>
> What more do you think is required?
I think the IS_HIGHBIT_SET needs to be integrated into the 'for' loop
more clearly; the 'if' check plus the comment above it is just
confusing.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
@ 2024-11-21 18:14 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-21 18:14 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 01:05:38PM -0500, Bruce Momjian wrote:
> On Thu, Nov 21, 2024 at 11:09:14AM -0600, Nathan Bossart wrote:
>> Yes, we still need to do that if it's possible the truncation wiped out
>> part of a multi-byte character. But it's not possible that we truncated
>> part of a multi-byte character if the NAMEDATALEN-1'th or NAMEDATALEN-2'th
>> byte is ASCII, in which case we can avoid doing extra lookups.
>
> Why would you check for two characters at the end rather than just a
> normal check in the main loop?
It might be possible to integrate this check into the loop, which could
potentially be cleaner. The reason I didn't at first is because it
requires checking a byte that we will have already truncated away. We have
to look at the original, non-truncated string for that. I'll give it a try
(unless Bertrand beats me to it).
>> What more do you think is required?
>
> I think the IS_HIGHBIT_SET needs to be integrated into the 'for' loop
> more clearly; the 'if' check plus the comment above it is just
> confusing.
Got it. Thank you for reviewing.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-22 07:45 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-22 07:45 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Bruce Momjian <bruce@momjian.us>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Thu, Nov 21, 2024 at 12:14:47PM -0600, Nathan Bossart wrote:
> On Thu, Nov 21, 2024 at 01:05:38PM -0500, Bruce Momjian wrote:
> > On Thu, Nov 21, 2024 at 11:09:14AM -0600, Nathan Bossart wrote:
> >> Yes, we still need to do that if it's possible the truncation wiped out
> >> part of a multi-byte character. But it's not possible that we truncated
> >> part of a multi-byte character if the NAMEDATALEN-1'th or NAMEDATALEN-2'th
> >> byte is ASCII, in which case we can avoid doing extra lookups.
> >
> > Why would you check for two characters at the end rather than just a
> > normal check in the main loop?
>
> It might be possible to integrate this check into the loop, which could
> potentially be cleaner. The reason I didn't at first is because it
> requires checking a byte that we will have already truncated away. We have
> to look at the original, non-truncated string for that. I'll give it a try
> (unless Bertrand beats me to it).
> >
> > I think the IS_HIGHBIT_SET needs to be integrated into the 'for' loop
> > more clearly; the 'if' check plus the comment above it is just
> > confusing.
>
> Got it. Thank you for reviewing.
What about something like in v3 attached? (I did a few tests and that seems to
work as expected).
If that's ok I can also look at the role part.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachments:
v3-0001-attempt-multibyte-aware-truncation-of-database-na.patch (text/x-diff, 0B) download
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-22 19:23 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-23 17:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
0 siblings, 2 replies; 67+ messages in thread
From: Tom Lane @ 2024-11-22 19:23 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> What about something like in v3 attached? (I did a few tests and that seems to
> work as expected).
After more thought I don't really like the idea of failing if there
are multiple matches. It means that we might fail in cases where
pre-v17 worked fine (because NAMEDATALEN-1 was accidentally the
right truncation point). ISTM the entire point of this patch is to
restore the pre-v17 behavior as much as possible, so that seems like
the wrong outcome.
So that means we could do something like the attached. (There's
room for argument about which error messages in InitPostgres
should use in_dbname versus the truncated name, but I chose to
use in_dbname for the two "does not exist" reports.)
I didn't try to write a test case, but we probably should have one.
regards, tom lane
Attachments:
v4-attempt-multibyte-aware-truncation.patch (text/x-diff, 4.9K) download
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 5b657a3f13..62be5f2d20 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -68,6 +68,7 @@
#include "utils/timeout.h"
static HeapTuple GetDatabaseTuple(const char *dbname);
+static HeapTuple GetDatabaseTupleInternal(Relation relation, const char *dbname);
static HeapTuple GetDatabaseTupleByOid(Oid dboid);
static void PerformAuthentication(Port *port);
static void CheckMyDatabase(const char *name, bool am_superuser, bool override_allow_connections);
@@ -97,12 +98,79 @@ static void process_settings(Oid databaseid, Oid roleid);
* descriptors for both pg_database and its indexes from the shared relcache
* cache file, and so we can do an indexscan. criticalSharedRelcachesBuilt
* tells whether we got the cached descriptors.
+ *
+ * This function also deals with the trickier-than-it-sounds issue of
+ * truncating an overlength incoming database name. We do not know which
+ * encoding the name is in, so we can't apply pg_encoding_mbcliplen() as
+ * CREATE DATABASE would have done. We use the heuristic of truncating one
+ * byte at a time until we find a match in pg_database, relying on the
+ * assumption that the name as stored in pg_database is valid according to
+ * some server-side encoding. This lets us constrain the search using the
+ * fact that all bytes of a multibyte character have their high bit set.
*/
static HeapTuple
GetDatabaseTuple(const char *dbname)
{
- HeapTuple tuple;
+ HeapTuple tuple = NULL;
Relation relation;
+ char tname[NAMEDATALEN];
+
+ relation = table_open(DatabaseRelationId, AccessShareLock);
+
+ if (strlen(dbname) < NAMEDATALEN)
+ {
+ /* Typical, easy case: no truncation needed */
+ tuple = GetDatabaseTupleInternal(relation, dbname);
+ }
+ else if (!IS_HIGHBIT_SET(dbname[NAMEDATALEN - 1]) ||
+ !IS_HIGHBIT_SET(dbname[NAMEDATALEN - 2]))
+ {
+ /* Also easy: truncation at NAMEDATALEN - 1 cannot break an MB char */
+ memcpy(tname, dbname, sizeof(tname));
+ tname[NAMEDATALEN - 1] = '\0';
+ tuple = GetDatabaseTupleInternal(relation, tname);
+ }
+ else
+ {
+ /* Hard case: try the successive-truncation heuristic */
+ memcpy(tname, dbname, sizeof(tname));
+ for (int i = NAMEDATALEN - 1;
+ i >= NAMEDATALEN - MAX_MULTIBYTE_CHAR_LEN;
+ i--)
+ {
+ /*
+ * If the byte we're about to remove is ASCII, it cannot be part
+ * of a multibyte character, so truncating it would be incorrect.
+ */
+ if (!IS_HIGHBIT_SET(tname[i]))
+ break;
+ tname[i] = '\0';
+
+ tuple = GetDatabaseTupleInternal(relation, tname);
+
+ /*
+ * Take the first match. It's theoretically possible that we
+ * could find more than one match if we continued to try shorter
+ * truncations (which is what makes this a heuristic). This is
+ * unlikely though. We considered failing if there are multiple
+ * candidate matches, but that cure seems worse than the disease:
+ * it might reject cases that worked fine before v17.
+ */
+ if (HeapTupleIsValid(tuple))
+ break;
+ }
+ }
+
+ table_close(relation, AccessShareLock);
+
+ return tuple;
+}
+
+/* One tuple fetch for GetDatabaseTuple */
+static HeapTuple
+GetDatabaseTupleInternal(Relation relation, const char *dbname)
+{
+ HeapTuple tuple;
SysScanDesc scan;
ScanKeyData key[1];
@@ -115,11 +183,10 @@ GetDatabaseTuple(const char *dbname)
CStringGetDatum(dbname));
/*
- * Open pg_database and fetch a tuple. Force heap scan if we haven't yet
- * built the critical shared relcache entries (i.e., we're starting up
- * without a shared relcache cache file).
+ * Try to fetch the tuple. Force heap scan if we haven't yet built the
+ * critical shared relcache entries (i.e., we're starting up without a
+ * shared relcache cache file).
*/
- relation = table_open(DatabaseRelationId, AccessShareLock);
scan = systable_beginscan(relation, DatabaseNameIndexId,
criticalSharedRelcachesBuilt,
NULL,
@@ -133,7 +200,6 @@ GetDatabaseTuple(const char *dbname)
/* all done */
systable_endscan(scan);
- table_close(relation, AccessShareLock);
return tuple;
}
@@ -1011,6 +1077,8 @@ InitPostgres(const char *in_dbname, Oid dboid,
errmsg("database \"%s\" does not exist", in_dbname)));
dbform = (Form_pg_database) GETSTRUCT(tuple);
dboid = dbform->oid;
+ /* Save the real (possibly truncated) database name */
+ strlcpy(dbname, NameStr(dbform->datname), sizeof(dbname));
}
else if (!OidIsValid(dboid))
{
@@ -1066,8 +1134,9 @@ InitPostgres(const char *in_dbname, Oid dboid,
if (HeapTupleIsValid(tuple))
datform = (Form_pg_database) GETSTRUCT(tuple);
+ /* Note comparison here must be against the truncated DB name */
if (!HeapTupleIsValid(tuple) ||
- (in_dbname && namestrcmp(&datform->datname, in_dbname)))
+ (in_dbname && namestrcmp(&datform->datname, dbname) != 0))
{
if (in_dbname)
ereport(FATAL,
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-22 20:01 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:06 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-23 08:37 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
1 sibling, 3 replies; 67+ messages in thread
From: Nathan Bossart @ 2024-11-22 20:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Fri, Nov 22, 2024 at 02:23:47PM -0500, Tom Lane wrote:
> After more thought I don't really like the idea of failing if there
> are multiple matches. It means that we might fail in cases where
> pre-v17 worked fine (because NAMEDATALEN-1 was accidentally the
> right truncation point). ISTM the entire point of this patch is to
> restore the pre-v17 behavior as much as possible, so that seems like
> the wrong outcome.
That's fine with me.
> So that means we could do something like the attached. (There's
> room for argument about which error messages in InitPostgres
> should use in_dbname versus the truncated name, but I chose to
> use in_dbname for the two "does not exist" reports.)
Looks reasonable to me. I had been thinking of ways to simplify this code
based on Bruce's feedback, and I came up with the attached. If nothing
else, this at least helps minimize the amount of code that is only reached
in extremely rare cases, but it's probably not quite as performant as v4
for the usual path, so v4 may still be the way to go.
I think we'll also want to do something about MyProcPort->database_name
(and the user name, of course). In a previous patch, I tried to update it
when a match was found, but maybe it'd be better to postpone setting those
values at all until after we've found the database tuple. AFAICT they are
only used for the process title before this code is reached.
--
nathan
Attachments:
v5-attempt-multibyte-aware-truncation.patch (text/plain, 4.7K) download
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 5b657a3f13..bfbc41aceb 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -68,6 +68,7 @@
#include "utils/timeout.h"
static HeapTuple GetDatabaseTuple(const char *dbname);
+static HeapTuple GetDatabaseTupleInternal(Relation relation, const char *dbname);
static HeapTuple GetDatabaseTupleByOid(Oid dboid);
static void PerformAuthentication(Port *port);
static void CheckMyDatabase(const char *name, bool am_superuser, bool override_allow_connections);
@@ -97,12 +98,72 @@ static void process_settings(Oid databaseid, Oid roleid);
* descriptors for both pg_database and its indexes from the shared relcache
* cache file, and so we can do an indexscan. criticalSharedRelcachesBuilt
* tells whether we got the cached descriptors.
+ *
+ * This function also deals with the trickier-than-it-sounds issue of
+ * truncating an overlength incoming database name. We do not know which
+ * encoding the name is in, so we can't apply pg_encoding_mbcliplen() as
+ * CREATE DATABASE would have done. We use the heuristic of truncating one
+ * byte at a time until we find a match in pg_database, relying on the
+ * assumption that the name as stored in pg_database is valid according to
+ * some server-side encoding. This lets us constrain the search using the
+ * fact that all bytes of a multibyte character have their high bit set.
*/
static HeapTuple
GetDatabaseTuple(const char *dbname)
{
HeapTuple tuple;
Relation relation;
+ char tname[NAMEDATALEN];
+
+ relation = table_open(DatabaseRelationId, AccessShareLock);
+
+ for (int i = NAMEDATALEN - 1;
+ i >= NAMEDATALEN - MAX_MULTIBYTE_CHAR_LEN;
+ i--)
+ {
+ strncpy(tname, dbname, sizeof(tname));
+ tname[i] = '\0';
+
+ /*
+ * Take the first match. It's theoretically possible that we could
+ * find more than one match if we continued to try shorter truncations
+ * (which is what makes this a heuristic). This is unlikely though.
+ * We considered failing if there are multiple candidate matches, but
+ * that cure seems worse than the disease: it might reject cases that
+ * worked fine before v17.
+ */
+ tuple = GetDatabaseTupleInternal(relation, tname);
+ if (HeapTupleIsValid(tuple))
+ break;
+
+ /*
+ * On the first iteration, check if we actually truncated anything.
+ * If not, then we don't need to bother with the successive-truncation
+ * heuristic.
+ */
+ if (i == NAMEDATALEN - 1 && strlen(dbname) < NAMEDATALEN)
+ break;
+
+ /*
+ * If the bytes at the truncation point are ASCII characters, we know
+ * that they cannot both be part of the same character, so the
+ * original truncation by CREATE/ALTER DATABASE would have gone no
+ * further.
+ */
+ if (!IS_HIGHBIT_SET(dbname[i]) || !IS_HIGHBIT_SET(dbname[i - 1]))
+ break;
+ }
+
+ table_close(relation, AccessShareLock);
+
+ return tuple;
+}
+
+/* One tuple fetch for GetDatabaseTuple */
+static HeapTuple
+GetDatabaseTupleInternal(Relation relation, const char *dbname)
+{
+ HeapTuple tuple;
SysScanDesc scan;
ScanKeyData key[1];
@@ -115,11 +176,10 @@ GetDatabaseTuple(const char *dbname)
CStringGetDatum(dbname));
/*
- * Open pg_database and fetch a tuple. Force heap scan if we haven't yet
- * built the critical shared relcache entries (i.e., we're starting up
- * without a shared relcache cache file).
+ * Try to fetch the tuple. Force heap scan if we haven't yet built the
+ * critical shared relcache entries (i.e., we're starting up without a
+ * shared relcache cache file).
*/
- relation = table_open(DatabaseRelationId, AccessShareLock);
scan = systable_beginscan(relation, DatabaseNameIndexId,
criticalSharedRelcachesBuilt,
NULL,
@@ -133,7 +193,6 @@ GetDatabaseTuple(const char *dbname)
/* all done */
systable_endscan(scan);
- table_close(relation, AccessShareLock);
return tuple;
}
@@ -1011,6 +1070,8 @@ InitPostgres(const char *in_dbname, Oid dboid,
errmsg("database \"%s\" does not exist", in_dbname)));
dbform = (Form_pg_database) GETSTRUCT(tuple);
dboid = dbform->oid;
+ /* Save the real (possibly truncated) database name */
+ strlcpy(dbname, NameStr(dbform->datname), sizeof(dbname));
}
else if (!OidIsValid(dboid))
{
@@ -1066,8 +1127,9 @@ InitPostgres(const char *in_dbname, Oid dboid,
if (HeapTupleIsValid(tuple))
datform = (Form_pg_database) GETSTRUCT(tuple);
+ /* Note comparison here must be against the truncated DB name */
if (!HeapTupleIsValid(tuple) ||
- (in_dbname && namestrcmp(&datform->datname, in_dbname)))
+ (in_dbname && namestrcmp(&datform->datname, dbname) != 0))
{
if (in_dbname)
ereport(FATAL,
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-22 20:06 ` Nathan Bossart <nathandbossart@gmail.com>
2 siblings, 0 replies; 67+ messages in thread
From: Nathan Bossart @ 2024-11-22 20:06 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Fri, Nov 22, 2024 at 02:01:41PM -0600, Nathan Bossart wrote:
> static HeapTuple
> GetDatabaseTuple(const char *dbname)
> {
> HeapTuple tuple;
> Relation relation;
> + char tname[NAMEDATALEN];
(tuple should be initialized to NULL here. I accidentally left that out.)
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-22 20:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-22 20:07 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> I think we'll also want to do something about MyProcPort->database_name
Huh, isn't that getting filled from InitPostgres's out_dbname?
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-22 20:17 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-22 20:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Fri, Nov 22, 2024 at 03:07:46PM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> I think we'll also want to do something about MyProcPort->database_name
>
> Huh, isn't that getting filled from InitPostgres's out_dbname?
I think ProcessStartupPacket() sets it. That's called by
BackendInitialize(), which is called before PostgresMain() (which is what
ultimately calls InitPostgres()). The truncation used to happen within
ProcessStartupPacket(), and it updated MyProcPort directly.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-27 15:40 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-27 15:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Fri, Nov 22, 2024 at 02:17:07PM -0600, Nathan Bossart wrote:
> On Fri, Nov 22, 2024 at 03:07:46PM -0500, Tom Lane wrote:
>> Nathan Bossart <nathandbossart@gmail.com> writes:
>>> I think we'll also want to do something about MyProcPort->database_name
>>
>> Huh, isn't that getting filled from InitPostgres's out_dbname?
>
> I think ProcessStartupPacket() sets it. That's called by
> BackendInitialize(), which is called before PostgresMain() (which is what
> ultimately calls InitPostgres()). The truncation used to happen within
> ProcessStartupPacket(), and it updated MyProcPort directly.
Here's an attempt at dealing with this problem. I've just taught
PostgresMain() to use out_dbname to update MyProcPort->database_name and
the process title as needed. Of course, we still need to handle role
names, too...
That being said, I'm growing quite uneasy about the size of this hack, and
I'm wondering if it would be better to leave it alone (perhaps with an
update to the release notes) or just revert commit 562bee0 until we have a
better way of dealing with multibyte characters in identifiers (e.g.,
tracking their encoding). I suspect there are similar problems in other
places (e.g., pg_dumpall).
--
nathan
Attachments:
v8-0001-fix-database-name-truncation.patch (text/plain, 0B) download
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-27 16:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
0 siblings, 2 replies; 67+ messages in thread
From: Tom Lane @ 2024-11-27 16:03 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> That being said, I'm growing quite uneasy about the size of this hack, and
> I'm wondering if it would be better to leave it alone (perhaps with an
> update to the release notes) or just revert commit 562bee0 until we have a
> better way of dealing with multibyte characters in identifiers (e.g.,
> tracking their encoding). I suspect there are similar problems in other
> places (e.g., pg_dumpall).
Yeah, there is something to be said for reverting. There is nothing
about our handling of non-ASCII characters in shared system catalogs
that isn't squishy as heck, and yet there have been darn few field
complaints over the many years it's been like that. Maybe trying to
make this truncation issue better in isolation wasn't such a great
plan.
(If we recorded the encoding of names in shared catalogs then this
particular issue would be far easier to solve, but then we have
other problems to address --- particularly, what to do if a name
in the catalog fails to convert to the encoding we are using.)
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-27 16:36 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-27 16:36 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Wed, Nov 27, 2024 at 11:03:36AM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
> > That being said, I'm growing quite uneasy about the size of this hack, and
> > I'm wondering if it would be better to leave it alone (perhaps with an
> > update to the release notes) or just revert commit 562bee0 until we have a
> > better way of dealing with multibyte characters in identifiers (e.g.,
> > tracking their encoding). I suspect there are similar problems in other
> > places (e.g., pg_dumpall).
>
> Yeah, there is something to be said for reverting.
Agree that the size of the hack is growing quite uneasy.
But also it is not (because it currently just can't be) "perfect" (as in case of
multiple matches it would pick up the first one).
Producing multiple possible matches could be as simple as:
CREATE DATABASE "aäääääääääääääääääääääääääääääää";
CREATE DATABASE "aääääääääääääääääääääääääääääää";
and then:
psql -d "aääääääääääääääääääääääääääääääää"
I said "simple" because:
- both pg_database.datname are in the same encoding.
- none are truncated at creation time.
I think that could easily lead to bad surprise.
Leaving the current behavior (as in 17) alone has the pros of being consistent
for both ASCII and non-ASCII characters (as compared to reverting).
I'd vote for "leave it alone" or wait to see if we get more reports before
deciding.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-27 16:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-27 16:50 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Nov 27, 2024 at 04:36:07PM +0000, Bertrand Drouvot wrote:
> I'd vote for "leave it alone" or wait to see if we get more reports before
> deciding.
Did your initial report originate from users or from just exploring the
code? If it's the latter, then AFAICT this thread is really the only
feedback from the field we have to go on, and IMHO it'd be better to
proceed with reverting. But if you were fielding complaints from users,
then perhaps there is more room for discussion.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-27 17:43 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 17:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-27 17:43 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Wed, Nov 27, 2024 at 10:50:18AM -0600, Nathan Bossart wrote:
> On Wed, Nov 27, 2024 at 04:36:07PM +0000, Bertrand Drouvot wrote:
> > I'd vote for "leave it alone" or wait to see if we get more reports before
> > deciding.
>
> Did your initial report originate from users or from just exploring the
> code? If it's the latter, then AFAICT this thread is really the only
> feedback from the field we have to go on, and IMHO it'd be better to
> proceed with reverting.
I meant to say get more reports regarding the 17 behavior to decide between
reverting or "leave it alone".
Regarding the question, the report that lead to the initial discussion was coming
from a real case from an internal team. 562bee0fc1 did not fix it though but at
least provides a consistent behavior between ASCII and non-ASCII.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-27 17:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-27 17:50 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Nov 27, 2024 at 05:43:38PM +0000, Bertrand Drouvot wrote:
> Regarding the question, the report that lead to the initial discussion was coming
> from a real case from an internal team. 562bee0fc1 did not fix it though but at
> least provides a consistent behavior between ASCII and non-ASCII.
It may be more consistent, but if it didn't fix the issue for that user,
and it's breaking things for other users, then the added consistency seems
to have helped no one.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 17:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-27 18:03 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 18:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-27 18:03 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Nov 27, 2024 at 11:50:19AM -0600, Nathan Bossart wrote:
> On Wed, Nov 27, 2024 at 05:43:38PM +0000, Bertrand Drouvot wrote:
> > Regarding the question, the report that lead to the initial discussion was coming
> > from a real case from an internal team. 562bee0fc1 did not fix it though but at
> > least provides a consistent behavior between ASCII and non-ASCII.
>
> It may be more consistent, but if it didn't fix the issue for that user,
> and it's breaking things for other users, then the added consistency seems
> to have helped no one.
Right. That would just avoid new "surprises" like the one that lead to the initial
discussion. But as the pre-17 behavior was there since long enough, it looks like
that the "surprises" are not that frequent though (or not reported).
Indeed, reverting might be the way to go then (without waiting for more 17
behavior reports).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 17:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-27 18:12 ` Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 0 replies; 67+ messages in thread
From: Nathan Bossart @ 2024-11-27 18:12 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Nov 27, 2024 at 06:03:43PM +0000, Bertrand Drouvot wrote:
> Indeed, reverting might be the way to go then (without waiting for more 17
> behavior reports).
Okay. I'll plan on reverting it early next week.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 17:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-27 18:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 19:34 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-27 18:17 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> Indeed, reverting might be the way to go then (without waiting for more 17
> behavior reports).
I have an idea that might salvage something from what we've just
been doing. The biggest single problem with the old behavior,
AIUI, was the possibility of sending back encoding-corrupt names
in connection failure reports. How about something like:
* Don't truncate the names on sight (so we keep 562bee0fc1).
* Truncate the names at NAMEDATALEN-1 just before catalog lookup
(this restores the old lookup behavior, solving the current report).
* In lookup-failure messages, be sure to report the un-truncated
name (avoiding the bad-encoding problem).
* Copy the correctly-truncated names from the catalog to any
persistent storage such as MyProcPort, so that those are used
for all post-connection purposes.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 17:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 18:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-27 19:34 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-28 08:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-27 19:34 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Nov 27, 2024 at 01:17:18PM -0500, Tom Lane wrote:
> I have an idea that might salvage something from what we've just
> been doing. The biggest single problem with the old behavior,
> AIUI, was the possibility of sending back encoding-corrupt names
> in connection failure reports. How about something like:
>
> * Don't truncate the names on sight (so we keep 562bee0fc1).
>
> * Truncate the names at NAMEDATALEN-1 just before catalog lookup
> (this restores the old lookup behavior, solving the current report).
>
> * In lookup-failure messages, be sure to report the un-truncated
> name (avoiding the bad-encoding problem).
>
> * Copy the correctly-truncated names from the catalog to any
> persistent storage such as MyProcPort, so that those are used
> for all post-connection purposes.
One possible issue with truncating the names after-the-fact is that hooks
like ClientAuthentication_hook will have already been called with the
untruncated names. If it's just the connection failure reports we are
worried about, then maybe we should save the "raw" names to MyProcPort
before truncating and be sure to use those in the log messages.
I attached a rough sketch of what I'm imagining. If we aren't thrilled
about adding new fields to "struct Port" in a minor release, we could just
do a straight revert on the back-branches and add that part to v18.
--
nathan
Attachments:
save_untruncated_names.patch (text/plain, 5.0K) download
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
index 47e8c91606..d81c3eeba9 100644
--- a/src/backend/libpq/auth.c
+++ b/src/backend/libpq/auth.c
@@ -320,7 +320,7 @@ auth_failed(Port *port, int status, const char *logdetail)
ereport(FATAL,
(errcode(errcode_return),
- errmsg(errstr, port->user_name),
+ errmsg(errstr, port->user_name_raw),
logdetail ? errdetail_log("%s", logdetail) : 0));
/* doesn't return */
@@ -459,14 +459,14 @@ ClientAuthentication(Port *port)
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
/* translator: last %s describes encryption state */
errmsg("pg_hba.conf rejects replication connection for host \"%s\", user \"%s\", %s",
- hostinfo, port->user_name,
+ hostinfo, port->user_name_raw,
encryption_state)));
else
ereport(FATAL,
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
/* translator: last %s describes encryption state */
errmsg("pg_hba.conf rejects connection for host \"%s\", user \"%s\", database \"%s\", %s",
- hostinfo, port->user_name,
+ hostinfo, port->user_name_raw,
port->database_name,
encryption_state)));
break;
@@ -526,7 +526,7 @@ ClientAuthentication(Port *port)
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
/* translator: last %s describes encryption state */
errmsg("no pg_hba.conf entry for replication connection from host \"%s\", user \"%s\", %s",
- hostinfo, port->user_name,
+ hostinfo, port->user_name_raw,
encryption_state),
HOSTNAME_LOOKUP_DETAIL(port)));
else
@@ -534,7 +534,7 @@ ClientAuthentication(Port *port)
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
/* translator: last %s describes encryption state */
errmsg("no pg_hba.conf entry for host \"%s\", user \"%s\", database \"%s\", %s",
- hostinfo, port->user_name,
+ hostinfo, port->user_name_raw,
port->database_name,
encryption_state),
HOSTNAME_LOOKUP_DETAIL(port)));
diff --git a/src/backend/tcop/backend_startup.c b/src/backend/tcop/backend_startup.c
index 2a96c81f92..3b60559ae9 100644
--- a/src/backend/tcop/backend_startup.c
+++ b/src/backend/tcop/backend_startup.c
@@ -830,6 +830,22 @@ ProcessStartupPacket(Port *port, bool ssl_done, bool gss_done)
if (port->database_name == NULL || port->database_name[0] == '\0')
port->database_name = pstrdup(port->user_name);
+ /*
+ * Prior to truncating, save the raw database and user names for log
+ * messages.
+ */
+ port->database_name_raw = pstrdup(port->database_name);
+ port->user_name_raw = pstrdup(port->user_name);
+
+ /*
+ * Truncate given database and user names to length of a Postgres name.
+ * This avoids lookup failures when overlength names are given.
+ */
+ if (strlen(port->database_name) >= NAMEDATALEN)
+ port->database_name[NAMEDATALEN - 1] = '\0';
+ if (strlen(port->user_name) >= NAMEDATALEN)
+ port->user_name[NAMEDATALEN - 1] = '\0';
+
if (am_walsender)
MyBackendType = B_WAL_SENDER;
else
diff --git a/src/backend/utils/init/miscinit.c b/src/backend/utils/init/miscinit.c
index 3b7b2ebec0..7e3740fa0f 100644
--- a/src/backend/utils/init/miscinit.c
+++ b/src/backend/utils/init/miscinit.c
@@ -798,7 +798,8 @@ InitializeSessionUserId(const char *rolename, Oid roleid, bool bypass_login_chec
return;
ereport(FATAL,
(errcode(ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION),
- errmsg("role \"%s\" does not exist", rolename)));
+ errmsg("role \"%s\" does not exist",
+ MyProcPort ? MyProcPort->user_name_raw : rolename)));
}
}
else
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 5b657a3f13..4f949a8f2d 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -1008,7 +1008,8 @@ InitPostgres(const char *in_dbname, Oid dboid,
if (!HeapTupleIsValid(tuple))
ereport(FATAL,
(errcode(ERRCODE_UNDEFINED_DATABASE),
- errmsg("database \"%s\" does not exist", in_dbname)));
+ errmsg("database \"%s\" does not exist",
+ MyProcPort ? MyProcPort->database_name_raw : in_dbname)));
dbform = (Form_pg_database) GETSTRUCT(tuple);
dboid = dbform->oid;
}
@@ -1072,7 +1073,8 @@ InitPostgres(const char *in_dbname, Oid dboid,
if (in_dbname)
ereport(FATAL,
(errcode(ERRCODE_UNDEFINED_DATABASE),
- errmsg("database \"%s\" does not exist", in_dbname),
+ errmsg("database \"%s\" does not exist",
+ MyProcPort ? MyProcPort->database_name_raw : in_dbname),
errdetail("It seems to have just been dropped or renamed.")));
else
ereport(FATAL,
diff --git a/src/include/libpq/libpq-be.h b/src/include/libpq/libpq-be.h
index 9109b2c334..9031cabfc7 100644
--- a/src/include/libpq/libpq-be.h
+++ b/src/include/libpq/libpq-be.h
@@ -232,6 +232,9 @@ typedef struct Port
char *raw_buf;
ssize_t raw_buf_consumed,
raw_buf_remaining;
+
+ char *database_name_raw;
+ char *user_name_raw;
} Port;
/*
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 17:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 18:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 19:34 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-28 08:12 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 0 replies; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-28 08:12 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Wed, Nov 27, 2024 at 01:34:22PM -0600, Nathan Bossart wrote:
> On Wed, Nov 27, 2024 at 01:17:18PM -0500, Tom Lane wrote:
> > I have an idea that might salvage something from what we've just
> > been doing. The biggest single problem with the old behavior,
> > AIUI, was the possibility of sending back encoding-corrupt names
> > in connection failure reports. How about something like:
> >
> > * Don't truncate the names on sight (so we keep 562bee0fc1).
> >
> > * Truncate the names at NAMEDATALEN-1 just before catalog lookup
> > (this restores the old lookup behavior, solving the current report).
> >
> > * In lookup-failure messages, be sure to report the un-truncated
> > name (avoiding the bad-encoding problem).
> >
> > * Copy the correctly-truncated names from the catalog to any
> > persistent storage such as MyProcPort, so that those are used
> > for all post-connection purposes.
+1 for not reporting an encoding-corrupt name in connection failure
reports.
> One possible issue with truncating the names after-the-fact is that hooks
> like ClientAuthentication_hook will have already been called with the
> untruncated names.
Yeah.
> If it's just the connection failure reports we are
> worried about, then maybe we should save the "raw" names to MyProcPort
> before truncating and be sure to use those in the log messages.
I think that makes sense. Bonus point: the ClientAuthentication_hook would have
both names (truncated and non-truncated) at its disposal.
> I attached a rough sketch of what I'm imagining. If we aren't thrilled
> about adding new fields to "struct Port" in a minor release, we could just
> do a straight revert on the back-branches and add that part to v18.
If we do a straight revert on 17 then that would mean switching back to
reporting truncated name (currently 17 reports non truncated names) and handle
correct truncation on "ASCII" database name connections.
If we back patch, then "only" one change is made (from an end user point of
view): handle correct truncation on "ASCII" database name connections.
OTOH:
- the 2 new members would have to be at the end of the struct (since they
are 8 bytes long and there is no existing padding holes that could host them).
- I did a quick check in the commit log history and I did not see any change in
the Port struct that has been back-patched.
Based on the above, it might be better to just do a straight revert on 17.
+ /*
+ * Truncate given database and user names to length of a Postgres name.
+ * This avoids lookup failures when overlength names are given.
+ */
This is the exact comment prior to 562bee0fc1, worth to add a few words about
the non-ASCII case?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-28 12:22 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 67+ messages in thread
From: Thomas Munro @ 2024-11-28 12:22 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 28, 2024 at 5:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> There is nothing
> about our handling of non-ASCII characters in shared system catalogs
> that isn't squishy as heck, and yet there have been darn few field
> complaints over the many years it's been like that. Maybe trying to
> make this truncation issue better in isolation wasn't such a great
> plan.
I guess most people in Unix-land just use UTF-8 in every layer of
their software stack these days, so don't often see confused encodings
anymore? But I don't think that's true in the other place, where they
still routinely juggle multiple encodings and see garbled junk when it
goes wrong[1]. They might still generally prefer UTF-8 for database
encoding though, IDK.
> (If we recorded the encoding of names in shared catalogs then this
> particular issue would be far easier to solve, but then we have
> other problems to address --- particularly, what to do if a name
> in the catalog fails to convert to the encoding we are using.)
Here is a much dumber coarse-grained way I have wondered about for
making the encoding certain, without having to do any new conversions
at all: (1) single-encoding cluster mode, shared catalogues use same
encoding as all databases, (2) multi-encoding cluster mode with
ASCII-only shared catalogues, and (3) legacy squishy/raw mode you
normally only reach by pg_upgrade. Maybe you could switch between
them with an operation that validates names.
Then I think you could always know the shared cat encoding even with
no database context, and when you are connected to a database you
could mostly just carry on assuming it's database encoding (either it
is, or it's the ASCII subset). That can only be wrong in mode 3, all
bets off just like today, but that's your own fault for using mode 3.
I guess serious users of multi-encoding clusters already learn to
stick to ASCII-only role names and database names anyway, unless they
like seeing garbage?
[1] https://www.postgresql.org/message-id/flat/00a601db3b20%24b00261e0%24100725a0%24%40gmx.net
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-28 16:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-28 16:45 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Nov 28, 2024 at 5:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> (If we recorded the encoding of names in shared catalogs then this
>> particular issue would be far easier to solve, but then we have
>> other problems to address --- particularly, what to do if a name
>> in the catalog fails to convert to the encoding we are using.)
> Here is a much dumber coarse-grained way I have wondered about for
> making the encoding certain, without having to do any new conversions
> at all: (1) single-encoding cluster mode, shared catalogues use same
> encoding as all databases, (2) multi-encoding cluster mode with
> ASCII-only shared catalogues, and (3) legacy squishy/raw mode you
> normally only reach by pg_upgrade. Maybe you could switch between
> them with an operation that validates names.
Hmm, yeah maybe that could work. The other consideration here
(which we've been dancing around in this thread) is "what encoding
are role and database names in startup packets presented in?"
But I think your idea addresses that too:
* mode 1: incoming names must be in the One True Encoding
* mode 2: incoming names must be ASCII
* mode 3: same wild-west behavior as always
In modes 1 and 2 we could validate that the string meets our
expectations (and then truncate it correctly, too).
> I guess serious users of multi-encoding clusters already learn to
> stick to ASCII-only role names and database names anyway, unless they
> like seeing garbage?
Probably ... that's been the recommendation in the small number
of cases that have been reported, IIRC. That suggests that mode 2
might be the most reasonable default.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-28 21:12 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Thomas Munro @ 2024-11-28 21:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Fri, Nov 29, 2024 at 5:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hmm, yeah maybe that could work. The other consideration here
> (which we've been dancing around in this thread) is "what encoding
> are role and database names in startup packets presented in?"
> But I think your idea addresses that too:
>
> * mode 1: incoming names must be in the One True Encoding
>
> * mode 2: incoming names must be ASCII
>
> * mode 3: same wild-west behavior as always
>
> In modes 1 and 2 we could validate that the string meets our
> expectations (and then truncate it correctly, too).
Perhaps we could have a property shared_catalog_encoding:, -1 for
unknown (mode 3), PG_SQL_ASCII (mode 2), or something else (mode 1).
I realise that PG_SQL_ASCII normally means bytes with no validation,
but we don't have an encoding that means ASCII with pg_is_ascii()
validation, and I think it'd be confusing if SQL_ASCII meant wild west
mode, IDK. To have any hope of being able to change it after initdb,
I think it has to be in the control file and suspect you might have to
take AEL on all affected catalogues while validating and changing it.
Some random UX sketches:
$ CREATE DATABASE foo ... ENCODING latin1;
ERROR: encoding LATIN1 does not match shared catalog encoding UTF8
HINT: To allow databases with different encodings,
shared_catalog_encoding must be SQL_ASCII (or UNKNOWN, not
recommended)
$ ALTER SYSTEM SET shared_catalog_encoding = 'SQL_ASCII';
ERROR: existing role name "frédéric" cannot be represented in SQL_ASCII
HINT: Rename all databases and roles to use only ASCII characters.
(I realise that ALTER SYSTEM is for GUCs, but something that sounds a
bit like that.)
$ CREATE ROLE lætitia;
ERROR: role name "lætitia" cannot be represented in the shared catalog
encoding SQL_ASCII
HINT: To allow non-ASCII roles, shared_catalog_encoding must be set to
an encoding matching all databases (or UNKNOWN, not recommended)
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
@ 2024-11-29 10:15 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-29 10:15 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Nathan Bossart <nathandbossart@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Fri, Nov 29, 2024 at 10:12:08AM +1300, Thomas Munro wrote:
> On Fri, Nov 29, 2024 at 5:45 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Hmm, yeah maybe that could work. The other consideration here
> > (which we've been dancing around in this thread) is "what encoding
> > are role and database names in startup packets presented in?"
> > But I think your idea addresses that too:
> >
> > * mode 1: incoming names must be in the One True Encoding
Yeah, in practice how would we do that? Just relying on pg_verify_mbstr()
or trying to do the actual "conversion"? Asking, because IIUC pg_verify_mbstr()
does not check for specific encoding rules for single byte (LATIN%) encoding.
> Perhaps we could have a property shared_catalog_encoding:, -1 for
> unknown (mode 3), PG_SQL_ASCII (mode 2), or something else (mode 1).
> I realise that PG_SQL_ASCII normally means bytes with no validation,
> but we don't have an encoding that means ASCII with pg_is_ascii()
> validation, and I think it'd be confusing if SQL_ASCII meant wild west
> mode, IDK.
hm, are you saying that when choosing PG_SQL_ASCII to represent Mode 2
(ASCII-only with validation) in the shared_catalog_encoding field,
we're giving it a different semantic meaning than it has elsewhere in the
system? Maybe we could just document very clearly that its meaning in
shared_catalog_encoding is special/different?
> To have any hope of being able to change it after initdb,
> I think it has to be in the control file and suspect you might have to
> take AEL on all affected catalogues
Yeah.
> Some random UX sketches:
>
> $ CREATE DATABASE foo ... ENCODING latin1;
> ERROR: encoding LATIN1 does not match shared catalog encoding UTF8
> HINT: To allow databases with different encodings,
> shared_catalog_encoding must be SQL_ASCII (or UNKNOWN, not
> recommended)
>
> $ ALTER SYSTEM SET shared_catalog_encoding = 'SQL_ASCII';
> ERROR: existing role name "frédéric" cannot be represented in SQL_ASCII
> HINT: Rename all databases and roles to use only ASCII characters.
>
> (I realise that ALTER SYSTEM is for GUCs, but something that sounds a
> bit like that.)
>
> $ CREATE ROLE lætitia;
> ERROR: role name "lætitia" cannot be represented in the shared catalog
> encoding SQL_ASCII
> HINT: To allow non-ASCII roles, shared_catalog_encoding must be set to
> an encoding matching all databases (or UNKNOWN, not recommended)
That would sound reasonable to me.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-12-02 05:39 ` Thomas Munro <thomas.munro@gmail.com>
2024-12-02 23:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-12-03 07:38 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 2 replies; 67+ messages in thread
From: Thomas Munro @ 2024-12-02 05:39 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Nathan Bossart <nathandbossart@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Fri, Nov 29, 2024 at 11:15 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> hm, are you saying that when choosing PG_SQL_ASCII to represent Mode 2
> (ASCII-only with validation) in the shared_catalog_encoding field,
> we're giving it a different semantic meaning than it has elsewhere in the
> system? Maybe we could just document very clearly that its meaning in
> shared_catalog_encoding is special/different?
Documentation seems enough to me. Unless you think it would be useful
outside this use case?
Hmm, in theory I suppose validated ASCII7 would be the ideal encoding
for template0, or generally any template that is allowed to be cloned
into a new database with a different encoding. It would enforce
something that is just a promise or convention today. I don't think
that is really a pressing issue in itself, the convention holds up
pretty well, but it's conceptually quite closely related, so it's at
least interesting to think about. I dunno.
> > $ CREATE ROLE lætitia;
> > ERROR: role name "lætitia" cannot be represented in the shared catalog
> > encoding SQL_ASCII
> > HINT: To allow non-ASCII roles, shared_catalog_encoding must be set to
> > an encoding matching all databases (or UNKNOWN, not recommended)
>
> That would sound reasonable to me.
Cool. You're both telling me this sounds worth trying out, so I
hacked up a proof-of-concept. Please see attached.
Almost half of the patch is tedious validation code that knows where
all the strings are hiding in the shared catalogs (and TODOs remain).
I wonder if that part could be automated somehow with schema analysis.
On the other hand, that stuff is not changing in a hurry, and you get
to write friendly actionable messages if you do it manually, for
example:
ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
ERROR: role "regress_fred" has setting "application_name" with value
"café" that contains invalid characters
HINT: Consider ALTER ROLE ... SET ... TO ... using characters valid
in SQL_ASCII.
(See lots more variations and cases in regress/expected/catalog_encoding.out.)
I'm on the fence about the default. Here I defaulted to
single-encoding, figuring that multi-encoding clusters are possibly a
fairly advanced configuration and that that user group could just run
one extra command, and there's even a HINT.
I wrote some documentation as an exercise to see how practical and
defensible the idea seemed when put into manualspeak.
Despite being a really simple idea for adding one new switch that
really only "stops" things rather than actually doing anything new, it
finishes up interacting with locking, logging, checkpointing, control
file, redo, grammar, pg_upgrade (and I see now that pg_dumpall might
need a similar approach), and I didn't even look at the startup stuff
you guys were working on that can hopefully benefit from having
GetSharedCatalogEncoding(). Hopefully the patch has the right sort of
ideas in some of those places, but obviously it's a rapid prototype so
might be way off on some of the details. It fails on Windows CI in a
very minor way that I see how to fix... later. It's enough to try out
the user experience anyway. Feedback, flames and ideas welcome.
Attachments:
v1-0001-Formalize-the-encoding-of-text-in-shared-catalogs.patch (text/x-patch, 67.7K) download
From d8405b1f34c826353933108f82d5ffc8a8082b53 Mon Sep 17 00:00:00 2001
From: Thomas Munro <thomas.munro@gmail.com>
Date: Sat, 30 Nov 2024 20:00:19 +1300
Subject: [PATCH v1] Formalize the encoding of text in shared catalogs.
The encoding of shared catalogs was previously undefined. Each database
assumed its own encoding, and early connection phases worked with raw
bytes and hoped for the best. Database names, role names, and more
could be corrupted in various scenarios.
This commit introduces a new cluster-wide property to track and enforce
the shared catalog encoding. It is selected at initdb time, and can be
changed later with the ALTER SYSTEM CATALOG ENCODING <encoding> command.
The chosen encoding imposes one of three different behaviors:
1. SQL_ASCII: Databases are allowed to use different encodings, but
database names, role names etc are restricted to 7-bit ASCII.
2. Any other encoding: All databases and the shared catalogs use the
same encoding. Database names, role names etc can use non-ASCII
characters, but databases cannot be created with different encodings.
3. UNKNOWN: Traditional behavior, supported for backwards
compatibility. Not recommended, and may be removed in a future release.
Work in progress!
Discussion: https://postgr.es/m/CA%2BhUKGKKNAc599Vp7kFAnLE1%3DV%3DceYujz_YQoSNrvNFGaJ6i7w%40mail.gmail.com
---
doc/src/sgml/catalogs.sgml | 2 +
doc/src/sgml/charset.sgml | 66 ++-
doc/src/sgml/ref/alter_system.sgml | 43 +-
doc/src/sgml/ref/initdb.sgml | 25 +
src/backend/access/rmgrdesc/xlogdesc.c | 10 +
src/backend/access/transam/xlog.c | 42 +-
src/backend/bootstrap/bootstrap.c | 9 +-
src/backend/catalog/Makefile | 1 +
src/backend/catalog/encoding.c | 429 ++++++++++++++++++
src/backend/catalog/meson.build | 1 +
src/backend/catalog/pg_db_role_setting.c | 5 +
src/backend/commands/alter.c | 18 +
src/backend/commands/comment.c | 3 +
src/backend/commands/dbcommands.c | 28 ++
src/backend/commands/seclabel.c | 3 +
src/backend/commands/subscriptioncmds.c | 6 +
src/backend/commands/tablespace.c | 4 +
src/backend/commands/user.c | 4 +
src/backend/parser/gram.y | 7 +
src/backend/replication/logical/origin.c | 2 +
src/backend/tcop/utility.c | 11 +-
src/bin/initdb/initdb.c | 28 +-
src/bin/pg_controldata/pg_controldata.c | 3 +
src/bin/pg_upgrade/pg_upgrade.c | 19 +
src/bin/psql/tab-complete.in.c | 11 +-
src/bin/scripts/t/020_createdb.pl | 4 +-
src/include/access/xlog.h | 5 +-
src/include/access/xlog_internal.h | 6 +
src/include/catalog/catalog.h | 2 +
src/include/catalog/pg_control.h | 5 +-
src/include/commands/alter.h | 2 +
src/include/nodes/parsenodes.h | 1 +
.../regress/expected/catalog_encoding.out | 171 +++++++
.../regress/expected/catalog_encoding_1.out | 3 +
src/test/regress/parallel_schedule | 2 +
src/test/regress/sql/catalog_encoding.sql | 138 ++++++
src/tools/pgindent/typedefs.list | 1 +
37 files changed, 1107 insertions(+), 13 deletions(-)
create mode 100644 src/backend/catalog/encoding.c
create mode 100644 src/test/regress/expected/catalog_encoding.out
create mode 100644 src/test/regress/expected/catalog_encoding_1.out
create mode 100644 src/test/regress/sql/catalog_encoding.sql
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 59bb833f48d..49deeae0b5f 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -36,6 +36,8 @@
database creation and are thereafter database-specific. A few
catalogs are physically shared across all databases in a cluster;
these are noted in the descriptions of the individual catalogs.
+ This has implications for their character set; see
+ <xref linkend="shared-catalog-encoding"/> for details.
</para>
<table id="catalog-table">
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index 00e1986849a..8b082ed4c56 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -2222,7 +2222,9 @@ initdb -E EUC_JP
<para>
You can specify a non-default encoding at database creation time,
- provided that the encoding is compatible with the selected locale:
+ provided that the encoding is compatible with the selected locale
+ and the shared catalog encoding is <literal>SQL_ASCII</literal>
+ (or <literal>UNKNOWN</literal>, not recommended).
<screen>
createdb -E EUC_KR -T template0 --lc-collate=ko_KR.euckr --lc-ctype=ko_KR.euckr korean
@@ -2401,6 +2403,68 @@ RESET client_encoding;
</para>
</sect2>
+ <sect2 id="shared-catalog-encoding">
+ <title>The Character Set used in Shared Catalogs</title>
+ <para>
+ The names of databases, roles and a small number of other object type
+ are
+ stored in <link linkend="catalogs-overview">shared system catalogs</link>,
+ and are visible from all the databases in a cluster.
+ Since databases can use different encodings, a trade-off is required to
+ maintain compatibility with the encoding used in the shared catalogs.
+ There are two main configurations:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Single-encoding clusters: To allow non-ASCII characters to be used in
+ database and role names, all databases must use the same encoding and
+ the shared catalog encoding must agree. By default,
+ <command>initdb</command> creates clusters this way.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Multi-encoding clusters: For databases with different
+ encodings to co-exist, the shared catalog encoding must be
+ <literal>SQL_ASCII</literal>. Database and role names are restricted
+ to the ASCII character set, in this context meaning strict 7-bit ASCII.
+ ASCII is a subset of all supported server encodings, so
+ conforming strings are also valid in every database's encoding without
+ conversion (or risk of conversion failure).
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ A third configuration is supported, but not recommened for new deployements:
+ The shared catalog encoding can be set to the special value
+ <literal>UNKNOWN</literal>
+ to allow databases with different encodings to co-exist while also allowing
+ non-ASCII characters in database and role names. In this configuration,
+ corruption may occur due to encoding mismatch. (This is the traditional
+ behavior of PostgreSQL releases before version 18.)
+ </para>
+ <para>
+ The shared catalog encoding can be selected with the
+ <xref linkend="app-initdb-option-catalog-encoding"/> option to <command>initdb</command>, or
+ changed later using the <xref linkend="sql-altersystem"/>
+ command. Later changes are only possible if certain conditions are met. For
+ <literal>SQL_ASCII</literal>, shared catalogs must contain no non-ASCII
+ characters, or an error message will identify the object preventing the change.
+ For any other encoding, all databases must be using that encoding.
+ Changing to <literal>UNKNOWN</literal> is always possible without restriction,
+ but not recommended.
+ </para>
+ <para>
+ Note that when shared catalog encoding is set to <literal>SQL_ASCII</literal>,
+ it only affects the names and properties of a small number of kinds of database
+ objects that have cluster-wide visibility. Most objects such as tables,
+ indexes and functions are stored in per-database catalogs and can always
+ use the full character set of the database's encoding.
+ </para>
+ </sect2>
+
<sect2 id="multibyte-conversions-supported">
<title>Available Character Set Conversions</title>
diff --git a/doc/src/sgml/ref/alter_system.sgml b/doc/src/sgml/ref/alter_system.sgml
index 1bde66d6ad2..e8fa5ebe890 100644
--- a/doc/src/sgml/ref/alter_system.sgml
+++ b/doc/src/sgml/ref/alter_system.sgml
@@ -25,6 +25,7 @@ ALTER SYSTEM SET <replaceable class="parameter">configuration_parameter</replace
ALTER SYSTEM RESET <replaceable class="parameter">configuration_parameter</replaceable>
ALTER SYSTEM RESET ALL
+ALTER SYSTEM CATALOG ENCODING { <replaceable class="parameter">encoding</replaceable> | UNKNOWN }
</synopsis>
</refsynopsisdiv>
@@ -32,7 +33,7 @@ ALTER SYSTEM RESET ALL
<title>Description</title>
<para>
- <command>ALTER SYSTEM</command> is used for changing server configuration
+ <command>ALTER SYSTEM { SET | RESET }</command> is used for changing server configuration
parameters across the entire database cluster. It can be more convenient
than the traditional method of manually editing
the <filename>postgresql.conf</filename> file.
@@ -46,7 +47,7 @@ ALTER SYSTEM RESET ALL
</para>
<para>
- Values set with <command>ALTER SYSTEM</command> will be effective after
+ Values set with <command>ALTER SYSTEM { SET | RESET }</command> will be effective after
the next server configuration reload, or after the next server restart
in the case of parameters that can only be changed at server start.
A server configuration reload can be commanded by calling the SQL
@@ -54,6 +55,15 @@ ALTER SYSTEM RESET ALL
or sending a <systemitem>SIGHUP</systemitem> signal to the main server process.
</para>
+ <para>
+ <command>ALTER SYSTEM CATALOG ENCODING</command> is used to control the encoding of
+ the shared catalogs, and affects the character set used for role names,
+ database names and the properties of certain other database objects that are shared
+ by all databases. See <xref linkend="shared-catalog-encoding"/> for details.
+ Unlike <command>ALTER SYSTEM SET</command>, this command takes effect immediately, if
+ the required conditions required are met.
+ </para>
+
<para>
Only superusers and users granted <literal>ALTER SYSTEM</literal> privilege
on a parameter can change it using <command>ALTER SYSTEM</command>. Also, since
@@ -96,6 +106,19 @@ ALTER SYSTEM RESET ALL
</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term><replaceable class="parameter">encoding</replaceable></term>
+ <listitem>
+ <para>
+ <literal>SQL_ASCII</literal> for the 7-bit ASCII character set.
+ The only other acceptable encoding is the one used by the current
+ database (since it must match all databases, it must at least match
+ this one).
+ </para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
</refsect1>
@@ -137,6 +160,22 @@ ALTER SYSTEM SET wal_level = replica;
<programlisting>
ALTER SYSTEM RESET wal_level;
</programlisting></para>
+
+ <para>
+ Change the shared catalog encoding to <literal>UTF8</literal>, so that
+ non-ASCII role names and database names can be used:
+<programlisting>
+ALTER SYSTEM CATALOG ENCODING UTF8;
+CREATE USER françois;
+</programlisting>
+
+ Try to change the shared catalog encoding to <literal>SQL_ASCII</literal>:
+<programlisting>
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: existing role name "françois" contains invalid characters
+HINT: Consider ALTER ROLE ... RENAME TO ... using characters valid in SQL_ASCII.
+</programlisting>
+ </para>
</refsect1>
<refsect1>
diff --git a/doc/src/sgml/ref/initdb.sgml b/doc/src/sgml/ref/initdb.sgml
index 0c32114cf70..6185cc47393 100644
--- a/doc/src/sgml/ref/initdb.sgml
+++ b/doc/src/sgml/ref/initdb.sgml
@@ -132,6 +132,10 @@ PostgreSQL documentation
<para>
To alter the default encoding, use the <option>--encoding</option>.
+ To specify a different encoding for the shared catalogs with
+ <option>--catalog-encoding</option>; this affects the character
+ set available for database and role names, and the ability to create
+ databases with different encodings.
More details can be found in <xref linkend="multibyte"/>.
</para>
@@ -227,6 +231,27 @@ PostgreSQL documentation
</listitem>
</varlistentry>
+ <varlistentry id="app-initdb-option-catalog-encoding">
+ <term><option>-C <replaceable class="parameter">encoding</replaceable></option></term>
+ <term><option>--catalog-encoding=<replaceable class="parameter">encoding</replaceable></option></term>
+ <listitem>
+ <para>
+ Selects the encoding of the shared catalogs.
+ </para>
+ <para>
+ By default, shared catalog encoding is set to match the default database
+ encoding, meaning that database and role names can use that full character
+ set but all databases must use that encoding. Alternatively,
+ <literal>SQL_ASCII</literal> can be specified to restrict the
+ character set for those object names to 7-bit ASCII, but allow databases
+ with different encodings. A third option <literal>UNKNOWN</literal>
+ is alway available, but not recommend. The shared catalog
+ encoding can be changed later, under certain conditions.
+ See <xref linkend="shared-catalog-encoding"/> for more details.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="app-initdb-allow-group-access">
<term><option>-g</option></term>
<term><option>--allow-group-access</option></term>
diff --git a/src/backend/access/rmgrdesc/xlogdesc.c b/src/backend/access/rmgrdesc/xlogdesc.c
index 363294d6234..3bbf0f2c9f1 100644
--- a/src/backend/access/rmgrdesc/xlogdesc.c
+++ b/src/backend/access/rmgrdesc/xlogdesc.c
@@ -134,6 +134,13 @@ xlog_desc(StringInfo buf, XLogReaderState *record)
xlrec.wal_log_hints ? "on" : "off",
xlrec.track_commit_timestamp ? "on" : "off");
}
+ else if (info == XLOG_CATALOG_ENCODING_CHANGE)
+ {
+ xl_catalog_encoding_change xlrec;
+
+ memcpy(&xlrec, rec, sizeof(xl_catalog_encoding_change));
+ appendStringInfo(buf, "encoding=%d", xlrec.encoding);
+ }
else if (info == XLOG_FPW_CHANGE)
{
bool fpw;
@@ -197,6 +204,9 @@ xlog_identify(uint8 info)
case XLOG_PARAMETER_CHANGE:
id = "PARAMETER_CHANGE";
break;
+ case XLOG_CATALOG_ENCODING_CHANGE:
+ id = "CATALOG_ENCODING_CHANGE";
+ break;
case XLOG_RESTORE_POINT:
id = "RESTORE_POINT";
break;
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index 6f58412bcab..5f2fa0c0472 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -70,6 +70,7 @@
#include "common/file_utils.h"
#include "executor/instrument.h"
#include "miscadmin.h"
+#include "mb/pg_wchar.h"
#include "pg_trace.h"
#include "pgstat.h"
#include "port/atomics.h"
@@ -5030,7 +5031,8 @@ XLOGShmemInit(void)
* and the initial XLOG segment.
*/
void
-BootStrapXLOG(uint32 data_checksum_version)
+BootStrapXLOG(int shared_catalog_encoding,
+ uint32 data_checksum_version)
{
CheckPoint checkPoint;
char *buffer;
@@ -5173,6 +5175,7 @@ BootStrapXLOG(uint32 data_checksum_version)
/* Now create pg_control */
InitControlFile(sysidentifier, data_checksum_version);
+ ControlFile->shared_catalog_encoding = shared_catalog_encoding;
ControlFile->time = checkPoint.time;
ControlFile->checkPoint = checkPoint.redo;
ControlFile->checkPointCopy = checkPoint;
@@ -8557,6 +8560,13 @@ xlog_redo(XLogReaderState *record)
/* Check to see if any parameter change gives a problem on recovery */
CheckRequiredParameterValues();
}
+ else if (info == XLOG_CATALOG_ENCODING_CHANGE)
+ {
+ xl_catalog_encoding_change xlrec;
+
+ memcpy(&xlrec, XLogRecGetData(record), sizeof(xlrec));
+ ControlFile->shared_catalog_encoding = xlrec.encoding;
+ }
else if (info == XLOG_FPW_CHANGE)
{
bool fpw;
@@ -9510,3 +9520,33 @@ SetWalWriterSleeping(bool sleeping)
XLogCtl->WalWriterSleeping = sleeping;
SpinLockRelease(&XLogCtl->info_lck);
}
+
+/*
+ * Get the shared catalog encoding. This should only be called when a lock is
+ * held on one of the shared catalog tables.
+ */
+int
+GetSharedCatalogEncoding(void)
+{
+ return ControlFile->shared_catalog_encoding;
+}
+
+/*
+ * Set the shared catalog encoding. This should only be called with
+ * AccessExclusiveLock held on *all* shared catalog tables that contain names.
+ */
+void
+SetSharedCatalogEncoding(int encoding)
+{
+ xl_catalog_encoding_change xlrec;
+
+ START_CRIT_SECTION();
+ MyProc->delayChkptFlags |= DELAY_CHKPT_START;
+ xlrec.encoding = encoding;
+ XLogBeginInsert();
+ XLogRegisterData((char *) &xlrec, sizeof(xlrec));
+ XLogFlush(XLogInsert(RM_XLOG_ID, XLOG_CATALOG_ENCODING_CHANGE));
+ ControlFile->shared_catalog_encoding = encoding;
+ MyProc->delayChkptFlags &= ~DELAY_CHKPT_START;
+ END_CRIT_SECTION();
+}
diff --git a/src/backend/bootstrap/bootstrap.c b/src/backend/bootstrap/bootstrap.c
index d31a67599c9..f6ee9752afa 100644
--- a/src/backend/bootstrap/bootstrap.c
+++ b/src/backend/bootstrap/bootstrap.c
@@ -202,6 +202,7 @@ BootstrapModeMain(int argc, char *argv[], bool check_only)
int flag;
char *userDoption = NULL;
uint32 bootstrap_data_checksum_version = 0; /* No checksum */
+ int shared_catalog_encoding = -1;
Assert(!IsUnderPostmaster);
@@ -217,7 +218,7 @@ BootstrapModeMain(int argc, char *argv[], bool check_only)
argv++;
argc--;
- while ((flag = getopt(argc, argv, "B:c:d:D:Fkr:X:-:")) != -1)
+ while ((flag = getopt(argc, argv, "B:c:C:d:D:Fkr:X:-:")) != -1)
{
switch (flag)
{
@@ -266,6 +267,9 @@ BootstrapModeMain(int argc, char *argv[], bool check_only)
pfree(debugstr);
}
break;
+ case 'C':
+ shared_catalog_encoding = atoi(optarg);
+ break;
case 'F':
SetConfigOption("fsync", "false", PGC_POSTMASTER, PGC_S_ARGV);
break;
@@ -341,7 +345,8 @@ BootstrapModeMain(int argc, char *argv[], bool check_only)
BaseInit();
bootstrap_signals();
- BootStrapXLOG(bootstrap_data_checksum_version);
+ BootStrapXLOG(shared_catalog_encoding,
+ bootstrap_data_checksum_version);
/*
* To ensure that src/common/link-canary.c is linked into the backend, we
diff --git a/src/backend/catalog/Makefile b/src/backend/catalog/Makefile
index 1589a75fd53..ed460a95e62 100644
--- a/src/backend/catalog/Makefile
+++ b/src/backend/catalog/Makefile
@@ -17,6 +17,7 @@ OBJS = \
aclchk.o \
catalog.o \
dependency.o \
+ encoding.o \
heap.o \
index.o \
indexing.o \
diff --git a/src/backend/catalog/encoding.c b/src/backend/catalog/encoding.c
new file mode 100644
index 00000000000..f8a1b95a536
--- /dev/null
+++ b/src/backend/catalog/encoding.c
@@ -0,0 +1,429 @@
+/*-------------------------------------------------------------------------
+ *
+ * encoding.c
+ * Shared catalog encoding management.
+ *
+ *
+ * Portions Copyright (c) 2024, PostgreSQL Global Development Group
+ * Portions Copyright (c) 1994, Regents of the University of California
+ *
+ *
+ * IDENTIFICATION
+ * src/backend/catalog/encoding.c
+ *
+ *-------------------------------------------------------------------------
+ */
+
+#include "postgres.h"
+
+#include "access/genam.h"
+#include "access/table.h"
+#include "access/xlog.h"
+#include "catalog/catalog.h"
+#include "catalog/pg_authid.h"
+#include "catalog/pg_database.h"
+#include "catalog/pg_db_role_setting.h"
+#include "catalog/pg_namespace.h"
+#include "catalog/pg_parameter_acl.h"
+#include "catalog/pg_replication_origin.h"
+#include "catalog/pg_shdescription.h"
+#include "catalog/pg_shseclabel.h"
+#include "catalog/pg_subscription.h"
+#include "catalog/pg_tablespace.h"
+#include "commands/dbcommands.h"
+#include "common/string.h"
+#include "mb/pg_wchar.h"
+#include "miscadmin.h"
+#include "storage/lmgr.h"
+#include "utils/builtins.h"
+
+/*
+ * Check if a NULL-terminated string can be inserted into a shared catalog.
+ * The caller must hold a lock on the shared catalog table, to block
+ * AlterSystemCatalogEncoding().
+ */
+void
+ValidateSharedCatalogString(Relation rel, const char *s)
+{
+ /*
+ * The main reason for taking the rel argument is to make sure that caller
+ * remembered to lock the catalog before validating strings to be
+ * inserted. But we might as well check it's a shared relation since we
+ * have it.
+ */
+ Assert(rel->rd_rel->relisshared);
+
+ /*
+ * If using SQL_ASCII, then we have to make sure this string is clean
+ * 7-bit ASCII, so that it is valid in every supported encoding.
+ */
+ if (GetSharedCatalogEncoding() != PG_SQL_ASCII)
+ {
+ /*
+ * Otherwise, either we're in UNKNOWN mode where anything goes, or all
+ * databases are using the same encoding and matches the shared
+ * catalog encoding. We don't have to validate anything.
+ */
+ Assert(GetSharedCatalogEncoding() == -1 ||
+ GetSharedCatalogEncoding() == GetDatabaseEncoding());
+ return;
+ }
+
+ if (!pg_is_ascii(s))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("the string \"%s\" contains characters that cannot be represented in SQL_ASCII",
+ s),
+ errhint("Consider ALTER SYSTEM CATALOG ENCODING %s.",
+ pg_encoding_to_char(GetDatabaseEncoding()))));
+}
+
+/*
+ * Try to change the shared catalog encoding, if all the conditions are met.
+ */
+void
+AlterSystemCatalogEncoding(const char *encoding_name)
+{
+ Relation rel;
+ SysScanDesc scan;
+ HeapTuple tup;
+ int encoding;
+
+ if (!superuser())
+ ereport(ERROR,
+ (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
+ errmsg("permission denied")));
+
+ /* Decode the name. */
+ if (pg_strcasecmp(encoding_name, "UNKNOWN") == 0)
+ encoding = -1;
+ else
+ {
+ /*
+ * The only encodings that can really work are SQL_ASCII and the
+ * current database's encoding, but we use the standard name lookup
+ * pattern because it tolerates some spelling variants.
+ */
+ encoding = pg_char_to_encoding(encoding_name);
+ if (encoding == -1)
+ ereport(ERROR,
+ (errcode(ERRCODE_UNDEFINED_OBJECT),
+ errmsg("%s is not a valid encoding name",
+ encoding_name)));
+ if (!PG_VALID_BE_ENCODING(encoding))
+ ereport(ERROR,
+ (errcode(ERRCODE_WRONG_OBJECT_TYPE),
+ errmsg("invalid server encoding %d",
+ encoding)));
+ }
+
+ /*
+ * Lock all of the shared catalog tables containing name or text values,
+ * to prevent concurrent updates. This is the set of shared catalogs that
+ * contain text. If new shared catalogs are invented that hold text they
+ * will need to be handled here too. For every validation that we perform
+ * below, there must also be corresponding calls to
+ * ValidateSharedCatalogString() in the commands that CREATE or ALTER
+ * these database objects.
+ */
+ LockRelationOid(AuthIdRelationId, AccessExclusiveLock);
+ LockRelationOid(DatabaseRelationId, AccessExclusiveLock);
+ LockRelationOid(DbRoleSettingRelationId, AccessExclusiveLock);
+ LockRelationOid(ParameterAclRelationId, AccessExclusiveLock);
+ LockRelationOid(ReplicationOriginRelationId, AccessExclusiveLock);
+ LockRelationOid(SharedDescriptionRelationId, AccessExclusiveLock);
+ LockRelationOid(SharedSecLabelRelationId, AccessExclusiveLock);
+ LockRelationOid(SubscriptionRelationId, AccessExclusiveLock);
+ LockRelationOid(TableSpaceRelationId, AccessExclusiveLock);
+
+ /* No change? */
+ if (GetSharedCatalogEncoding() == encoding)
+ return;
+
+ if (encoding == -1)
+ {
+ /* There are no encoding restrictions for UNKNOWN. Good luck. */
+ }
+ else if (encoding == PG_SQL_ASCII)
+ {
+ /* Make sure all shared catalogs contain only pure 7-bit ASCII. */
+
+ /* pg_authid */
+ rel = table_open(AuthIdRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ Form_pg_authid authid = (Form_pg_authid) GETSTRUCT(tup);
+
+ if (!pg_is_ascii(NameStr(authid->rolname)))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("existing role name \"%s\" contains invalid characters",
+ NameStr(authid->rolname)),
+ errhint("Consider ALTER ROLE ... RENAME TO ... using characters valid in SQL_ASCII.")));
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_database */
+ rel = table_open(DatabaseRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ Form_pg_database db = (Form_pg_database) GETSTRUCT(tup);
+
+ if (!pg_is_ascii(NameStr(db->datname)))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("existing database name \"%s\" contains invalid characters",
+ NameStr(db->datname)),
+ errhint("Consider ALTER DATABASE ... RENAME TO ... using characters valid in SQL_ASCII.")));
+
+ /*
+ * Locale-related text fields requiring heap tuple deforming
+ * should already have been validated as pure ASCII, so we don't
+ * have to work harder here.
+ *
+ * XXX That's only true for the LC_ stuff; what about ICU, should
+ * it get the same treatment, or be checked here?
+ */
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_db_role_setting */
+ rel = table_open(DbRoleSettingRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ bool isnull;
+ Datum setconfig;
+
+ setconfig = heap_getattr(tup, Anum_pg_db_role_setting_setconfig,
+ RelationGetDescr(rel), &isnull);
+ if (!isnull)
+ {
+ List *gucNames;
+ List *gucValues;
+ ListCell *lc1;
+ ListCell *lc2;
+
+ TransformGUCArray(DatumGetArrayTypeP(setconfig), &gucNames, &gucValues);
+ forboth(lc1, gucNames, lc2, gucValues)
+ {
+ char *name = lfirst(lc1);
+ char *value = lfirst(lc2);
+
+ if (!pg_is_ascii(name) || !pg_is_ascii(value))
+ {
+ Datum db_id;
+ Datum role_id;
+
+ db_id = heap_getattr(tup, Anum_pg_db_role_setting_setdatabase,
+ RelationGetDescr(rel), &isnull);
+ role_id = heap_getattr(tup, Anum_pg_db_role_setting_setrole,
+ RelationGetDescr(rel), &isnull);
+
+ if (DatumGetObjectId(db_id) == InvalidOid)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("role \"%s\" has setting \"%s\" with value \"%s\" that contains invalid characters",
+ GetUserNameFromId(DatumGetObjectId(role_id), false),
+ name,
+ value),
+ errhint("Consider ALTER ROLE ... SET ... TO ... using characters valid in SQL_ASCII.")));
+ else
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("role \"%s\" has setting \"%s\" with value \"%s\" in database \"%s\" that contains invalid characters",
+ GetUserNameFromId(DatumGetObjectId(role_id), false),
+ name,
+ value,
+ get_database_name(DatumGetObjectId(db_id))),
+ errhint("Consider ALTER ROLE ... IN DATABASE ... SET ... TO ... using characters valid in SQL_ASCII.")));
+ }
+ pfree(name);
+ pfree(value);
+ }
+ list_free(gucNames);
+ list_free(gucValues);
+ }
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_parameter_acl */
+ rel = table_open(ParameterAclRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ bool isnull;
+ char *parname;
+
+ parname = TextDatumGetCString(heap_getattr(tup, Anum_pg_parameter_acl_parname,
+ RelationGetDescr(rel), &isnull));
+
+ /*
+ * This probably shouldn't happen as they are GUC names, so it's
+ * hard to suggest a useful hint.
+ */
+ if (!pg_is_ascii(parname))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("existing ACL parameter name name \"%s\" contains invalid characters",
+ parname)));
+ pfree(parname);
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_replication_origin */
+ rel = table_open(ReplicationOriginRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ bool isnull;
+ char *s;
+
+ s = TextDatumGetCString(heap_getattr(tup, Anum_pg_replication_origin_roname,
+ RelationGetDescr(rel), &isnull));
+ if (!pg_is_ascii(s))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("replication origin \"%s\" contains invalid characters",
+ s),
+ errhint("Consider recreating the replication origin using characters valid in SQL_ASCII.")));
+ pfree(s);
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_shdescription */
+ rel = table_open(SharedDescriptionRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ bool isnull;
+ char *s;
+
+ s = TextDatumGetCString(heap_getattr(tup, Anum_pg_shdescription_description,
+ RelationGetDescr(rel), &isnull));
+ if (!pg_is_ascii(s))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("comment \"%s\" on a shared database object contains invalid characters",
+ s),
+ errhint("Consider COMMENT ON ... IS ... using characters valid in SQL_ASCII.")));
+ pfree(s);
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_shseclabel */
+ rel = table_open(SharedSecLabelRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ bool isnull;
+ char *s;
+
+ s = TextDatumGetCString(heap_getattr(tup, Anum_pg_shseclabel_provider,
+ RelationGetDescr(rel), &isnull));
+ if (!pg_is_ascii(s))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("security label provider name \"%s\" contains invalid characters",
+ s),
+ errhint("This security label provider cannot be used for shared database object with SQL_ASCII encoding.")));
+ pfree(s);
+
+ s = TextDatumGetCString(heap_getattr(tup, Anum_pg_shseclabel_label,
+ RelationGetDescr(rel), &isnull));
+ if (!pg_is_ascii(s))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("a security label on a shared database object contains invalid characters"),
+ errhint("Security labels applied to shared database objects must be representable in the new encoding.")));
+ pfree(s);
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_subscription */
+ rel = table_open(SubscriptionRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ bool isnull;
+ char *name;
+ char *s;
+
+ name = NameStr(*DatumGetName(heap_getattr(tup, Anum_pg_subscription_subname,
+ RelationGetDescr(rel), &isnull)));
+ if (!pg_is_ascii(name))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("existing subscription name \"%s\" contains invalid characters",
+ name),
+ errhint("Consider ALTER SUBSCRIPTION ... RENAME TO ... using characters valid in SQL_ASCII.")));
+
+ s = TextDatumGetCString(heap_getattr(tup, Anum_pg_subscription_subconninfo,
+ RelationGetDescr(rel), &isnull));
+ if (!pg_is_ascii(s))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("existing subscription \"%s\" has connection string \"%s\" containing invalid characters",
+ name, s),
+ errhint("Consider ALTER SUBSCRIPTION ... CONNECTION ... using characters valid in SQL_ASCII.")));
+ pfree(s);
+
+ /*
+ * subsynccommit, subslotname and suborigin have their own
+ * validation that requires ASCII, so no check for now.
+ */
+
+ /* XXX TODO check subpublications, a text[] */
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+
+ /* pg_tablespace */
+ rel = table_open(TableSpaceRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ Form_pg_tablespace ts = (Form_pg_tablespace) GETSTRUCT(tup);
+
+ if (!pg_is_ascii(NameStr(ts->spcname)))
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("existing tablespace name \"%s\" contains invalid characters",
+ NameStr(ts->spcname)),
+ errhint("Consider ALTER TABLESPACE ... RENAME TO ... using characters valid in SQL_ASCII.")));
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+ }
+ else
+ {
+ /* Make sure all databases are using this encoding. */
+ rel = table_open(DatabaseRelationId, NoLock);
+ scan = systable_beginscan(rel, InvalidOid, false, NULL, 0, NULL);
+ while ((tup = systable_getnext(scan)))
+ {
+ Form_pg_database db = (Form_pg_database) GETSTRUCT(tup);
+
+ if (db->encoding != encoding)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("database \"%s\" has incompatible encoding %s",
+ NameStr(db->datname),
+ pg_encoding_to_char(db->encoding))));
+ }
+ systable_endscan(scan);
+ table_close(rel, NoLock);
+ }
+
+ /* If we made it this far, we are allowed to change it. */
+ SetSharedCatalogEncoding(encoding);
+}
diff --git a/src/backend/catalog/meson.build b/src/backend/catalog/meson.build
index 2f3ded8a0e7..ba7ac5ce35f 100644
--- a/src/backend/catalog/meson.build
+++ b/src/backend/catalog/meson.build
@@ -4,6 +4,7 @@ backend_sources += files(
'aclchk.c',
'catalog.c',
'dependency.c',
+ 'encoding.c',
'heap.c',
'index.c',
'indexing.c',
diff --git a/src/backend/catalog/pg_db_role_setting.c b/src/backend/catalog/pg_db_role_setting.c
index 8c20f519fc0..ef81eb95d17 100644
--- a/src/backend/catalog/pg_db_role_setting.c
+++ b/src/backend/catalog/pg_db_role_setting.c
@@ -46,6 +46,11 @@ AlterSetting(Oid databaseid, Oid roleid, VariableSetStmt *setstmt)
NULL, 2, scankey);
tuple = systable_getnext(scan);
+ if (setstmt->name)
+ ValidateSharedCatalogString(rel, setstmt->name);
+ if (valuestr)
+ ValidateSharedCatalogString(rel, valuestr);
+
/*
* There are three cases:
*
diff --git a/src/backend/commands/alter.c b/src/backend/commands/alter.c
index a45f3bb6b83..8591f1e9bcf 100644
--- a/src/backend/commands/alter.c
+++ b/src/backend/commands/alter.c
@@ -1038,3 +1038,21 @@ AlterObjectOwner_internal(Oid classId, Oid objectId, Oid new_ownerId)
table_close(rel, RowExclusiveLock);
}
+
+/*
+ * Main entry point for ALTER SYSTEM command.
+ */
+void
+AlterSystem(AlterSystemStmt *stmt)
+{
+ if (stmt->setstmt)
+ {
+ /* ALTER SYSTEM [RE]SET ... */
+ AlterSystemSetConfigFile(stmt);
+ }
+ else if (stmt->encoding_name)
+ {
+ /* ALTER SYSTEM CATALOG ENCODING ... */
+ AlterSystemCatalogEncoding(stmt->encoding_name);
+ }
+}
diff --git a/src/backend/commands/comment.c b/src/backend/commands/comment.c
index e9d50fc7d87..f56d8624827 100644
--- a/src/backend/commands/comment.c
+++ b/src/backend/commands/comment.c
@@ -277,6 +277,9 @@ CreateSharedComments(Oid oid, Oid classoid, const char *comment)
shdescription = table_open(SharedDescriptionRelationId, RowExclusiveLock);
+ if (comment)
+ ValidateSharedCatalogString(shdescription, comment);
+
sd = systable_beginscan(shdescription, SharedDescriptionObjIndexId, true,
NULL, 2, skey);
diff --git a/src/backend/commands/dbcommands.c b/src/backend/commands/dbcommands.c
index aa91a396967..3a1cec8be3d 100644
--- a/src/backend/commands/dbcommands.c
+++ b/src/backend/commands/dbcommands.c
@@ -1429,6 +1429,32 @@ createdb(ParseState *pstate, const CreatedbStmt *stmt)
Assert((dblocprovider != COLLPROVIDER_LIBC && dblocale) ||
(dblocprovider == COLLPROVIDER_LIBC && !dblocale));
+ /*
+ * Check encoding of strings going into shared catalog. Locales have
+ * already been verified as ASCII by checklocale() so we skip those.
+ */
+ ValidateSharedCatalogString(pg_database_rel, dbname);
+ if (dblocale)
+ ValidateSharedCatalogString(pg_database_rel, dblocale);
+ if (dbicurules)
+ ValidateSharedCatalogString(pg_database_rel, dbicurules);
+ if (dbcollversion)
+ ValidateSharedCatalogString(pg_database_rel, dbcollversion);
+
+ /*
+ * Check encoding of the contents of the data, for compatibility with the
+ * shared catalogs.
+ */
+ if (GetSharedCatalogEncoding() != -1 &&
+ GetSharedCatalogEncoding() != PG_SQL_ASCII &&
+ GetSharedCatalogEncoding() != encoding)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
+ errmsg("encoding \"%s\" is not compatible with shared catalog encoding \"%s\"",
+ pg_encoding_to_char(encoding),
+ pg_encoding_to_char(GetSharedCatalogEncoding())),
+ errhint("Consider ALTER SYSTEM CATALOG ENCODING SQL_ASCII.")));
+
/* Form tuple */
new_record[Anum_pg_database_oid - 1] = ObjectIdGetDatum(dboid);
new_record[Anum_pg_database_datname - 1] =
@@ -1889,6 +1915,8 @@ RenameDatabase(const char *oldname, const char *newname)
*/
rel = table_open(DatabaseRelationId, RowExclusiveLock);
+ ValidateSharedCatalogString(rel, newname);
+
if (!get_db_info(oldname, AccessExclusiveLock, &db_id, NULL, NULL, NULL,
NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL))
ereport(ERROR,
diff --git a/src/backend/commands/seclabel.c b/src/backend/commands/seclabel.c
index 5607273bf9f..0dad1a09eac 100644
--- a/src/backend/commands/seclabel.c
+++ b/src/backend/commands/seclabel.c
@@ -363,6 +363,9 @@ SetSharedSecurityLabel(const ObjectAddress *object,
pg_shseclabel = table_open(SharedSecLabelRelationId, RowExclusiveLock);
+ ValidateSharedCatalogString(pg_shseclabel, provider);
+ ValidateSharedCatalogString(pg_shseclabel, label);
+
scan = systable_beginscan(pg_shseclabel, SharedSecLabelObjectIndexId, true,
NULL, 3, keys);
diff --git a/src/backend/commands/subscriptioncmds.c b/src/backend/commands/subscriptioncmds.c
index 03e97730e73..5fac449328c 100644
--- a/src/backend/commands/subscriptioncmds.c
+++ b/src/backend/commands/subscriptioncmds.c
@@ -552,6 +552,7 @@ CreateSubscription(ParseState *pstate, CreateSubscriptionStmt *stmt,
bits32 supported_opts;
SubOpts opts = {0};
AclResult aclresult;
+ ListCell *l;
/*
* Parse and check options.
@@ -619,6 +620,11 @@ CreateSubscription(ParseState *pstate, CreateSubscriptionStmt *stmt,
rel = table_open(SubscriptionRelationId, RowExclusiveLock);
+ ValidateSharedCatalogString(rel, stmt->subname);
+ ValidateSharedCatalogString(rel, stmt->conninfo);
+ foreach(l, stmt->publication)
+ ValidateSharedCatalogString(rel, strVal(lfirst(l)));
+
/* Check if name is used */
subid = GetSysCacheOid2(SUBSCRIPTIONNAME, Anum_pg_subscription_oid,
MyDatabaseId, CStringGetDatum(stmt->subname));
diff --git a/src/backend/commands/tablespace.c b/src/backend/commands/tablespace.c
index 8ebbd935b0c..f7105ce5bd3 100644
--- a/src/backend/commands/tablespace.c
+++ b/src/backend/commands/tablespace.c
@@ -311,6 +311,8 @@ CreateTableSpace(CreateTableSpaceStmt *stmt)
*/
rel = table_open(TableSpaceRelationId, RowExclusiveLock);
+ ValidateSharedCatalogString(rel, stmt->tablespacename);
+
if (IsBinaryUpgrade)
{
/* Use binary-upgrade override for tablespace oid */
@@ -941,6 +943,8 @@ RenameTableSpace(const char *oldname, const char *newname)
/* Search pg_tablespace */
rel = table_open(TableSpaceRelationId, RowExclusiveLock);
+ ValidateSharedCatalogString(rel, newname);
+
ScanKeyInit(&entry[0],
Anum_pg_tablespace_spcname,
BTEqualStrategyNumber, F_NAMEEQ,
diff --git a/src/backend/commands/user.c b/src/backend/commands/user.c
index e7ade898a47..02fae91c8d0 100644
--- a/src/backend/commands/user.c
+++ b/src/backend/commands/user.c
@@ -371,6 +371,8 @@ CreateRole(ParseState *pstate, CreateRoleStmt *stmt)
pg_authid_rel = table_open(AuthIdRelationId, RowExclusiveLock);
pg_authid_dsc = RelationGetDescr(pg_authid_rel);
+ ValidateSharedCatalogString(pg_authid_rel, stmt->role);
+
if (OidIsValid(get_role_oid(stmt->role, true)))
ereport(ERROR,
(errcode(ERRCODE_DUPLICATE_OBJECT),
@@ -1350,6 +1352,8 @@ RenameRole(const char *oldname, const char *newname)
rel = table_open(AuthIdRelationId, RowExclusiveLock);
dsc = RelationGetDescr(rel);
+ ValidateSharedCatalogString(rel, newname);
+
oldtuple = SearchSysCache1(AUTHNAME, CStringGetDatum(oldname));
if (!HeapTupleIsValid(oldtuple))
ereport(ERROR,
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 67eb96396af..53a0a826497 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -11540,6 +11540,13 @@ AlterSystemStmt:
n->setstmt = $4;
$$ = (Node *) n;
}
+ | ALTER SYSTEM_P CATALOG_P ENCODING name
+ {
+ AlterSystemStmt *n = makeNode(AlterSystemStmt);
+
+ n->encoding_name = $5;
+ $$ = (Node *) n;
+ }
;
diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c
index baf696d8e68..0a323ea2422 100644
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -286,6 +286,8 @@ replorigin_create(const char *roname)
rel = table_open(ReplicationOriginRelationId, ExclusiveLock);
+ ValidateSharedCatalogString(rel, roname);
+
for (roident = InvalidOid + 1; roident < PG_UINT16_MAX; roident++)
{
bool nulls[Natts_pg_replication_origin];
diff --git a/src/backend/tcop/utility.c b/src/backend/tcop/utility.c
index f28bf371059..e6e6e6ab824 100644
--- a/src/backend/tcop/utility.c
+++ b/src/backend/tcop/utility.c
@@ -218,6 +218,8 @@ ClassifyUtilityCommandAsReadOnly(Node *parsetree)
case T_AlterSystemStmt:
{
+ AlterSystemStmt *stmt = (AlterSystemStmt *) parsetree;
+
/*
* Surprisingly, ALTER SYSTEM meets all our definitions of
* read-only: it changes nothing that affects the output of
@@ -227,8 +229,13 @@ ClassifyUtilityCommandAsReadOnly(Node *parsetree)
*
* So, despite the fact that it writes to a file, it's read
* only!
+ *
+ * XXX ^ that's about ALTER SYSTEM SET only
*/
- return COMMAND_IS_STRICTLY_READ_ONLY;
+ if (stmt->setstmt)
+ return COMMAND_IS_STRICTLY_READ_ONLY;
+ else
+ return COMMAND_IS_NOT_READ_ONLY;
}
case T_CallStmt:
@@ -868,7 +875,7 @@ standard_ProcessUtility(PlannedStmt *pstmt,
case T_AlterSystemStmt:
PreventInTransactionBlock(isTopLevel, "ALTER SYSTEM");
- AlterSystemSetConfigFile((AlterSystemStmt *) parsetree);
+ AlterSystem((AlterSystemStmt *) parsetree);
break;
case T_VariableSetStmt:
diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
index 9a91830783e..423ecdf7d2b 100644
--- a/src/bin/initdb/initdb.c
+++ b/src/bin/initdb/initdb.c
@@ -137,6 +137,7 @@ static char *share_path = NULL;
/* values to be obtained from arguments */
static char *pg_data = NULL;
static char *encoding = NULL;
+static char *catalog_encoding = NULL;
static char *locale = NULL;
static char *lc_collate = NULL;
static char *lc_ctype = NULL;
@@ -173,6 +174,7 @@ static DataDirSyncMethod sync_method = DATA_DIR_SYNC_METHOD_FSYNC;
/* internal vars */
static const char *progname;
static int encodingid;
+static int catalog_encodingid;
static char *bki_file;
static char *hba_file;
static char *ident_file;
@@ -1593,6 +1595,7 @@ bootstrap_template1(void)
printfPQExpBuffer(&cmd, "\"%s\" --boot %s %s", backend_exec, boot_options, extra_options);
appendPQExpBuffer(&cmd, " -X %d", wal_segment_size_mb * (1024 * 1024));
+ appendPQExpBuffer(&cmd, " -C %d", catalog_encodingid);
if (data_checksums)
appendPQExpBuffer(&cmd, " -k");
if (debug)
@@ -2748,6 +2751,25 @@ setup_locale_encoding(void)
else
encodingid = get_encoding_id(encoding);
+ /* Choose initial value of shared_catalog_encoding. */
+ if (catalog_encoding == NULL)
+ catalog_encodingid = encodingid;
+ else if (pg_strcasecmp(catalog_encoding, "UNKNOWN") == 0)
+ catalog_encodingid = -1;
+ else if (pg_strcasecmp(catalog_encoding, "SQL_ASCII") == 0)
+ catalog_encodingid = PG_SQL_ASCII;
+ else if (pg_char_to_encoding(catalog_encoding) != encodingid)
+ {
+ pg_log_error("catalog encoding \"%s\" is invalid", catalog_encoding);
+ pg_log_error_detail("Valid values are UNKNOWN, SQL_ASCII or %s (the selected default database encoding)",
+ pg_encoding_to_char(encodingid));
+ exit(1);
+ }
+ else
+ catalog_encodingid = encodingid;
+ printf(_("The initial shared catalog encoding has been set to \"%s\".\n"),
+ catalog_encodingid == -1 ? "UNKNOWN " : pg_encoding_to_char(catalog_encodingid));
+
if (!check_locale_encoding(lc_ctype, encodingid) ||
!check_locale_encoding(lc_collate, encodingid))
exit(1); /* check_locale_encoding printed the error */
@@ -3146,6 +3168,7 @@ main(int argc, char *argv[])
static struct option long_options[] = {
{"pgdata", required_argument, NULL, 'D'},
{"encoding", required_argument, NULL, 'E'},
+ {"catalog-encoding", required_argument, NULL, 'C'},
{"locale", required_argument, NULL, 1},
{"lc-collate", required_argument, NULL, 2},
{"lc-ctype", required_argument, NULL, 3},
@@ -3224,7 +3247,7 @@ main(int argc, char *argv[])
/* process command-line options */
- while ((c = getopt_long(argc, argv, "A:c:dD:E:gkL:nNsST:U:WX:",
+ while ((c = getopt_long(argc, argv, "A:c:C:dD:E:gkL:nNsST:U:WX:",
long_options, &option_index)) != -1)
{
switch (c)
@@ -3272,6 +3295,9 @@ main(int argc, char *argv[])
case 'E':
encoding = pg_strdup(optarg);
break;
+ case 'C':
+ catalog_encoding = pg_strdup(optarg);
+ break;
case 'W':
pwprompt = true;
break;
diff --git a/src/bin/pg_controldata/pg_controldata.c b/src/bin/pg_controldata/pg_controldata.c
index 93a05d80ca7..4284cdda303 100644
--- a/src/bin/pg_controldata/pg_controldata.c
+++ b/src/bin/pg_controldata/pg_controldata.c
@@ -27,6 +27,7 @@
#include "common/controldata_utils.h"
#include "common/logging.h"
#include "getopt_long.h"
+#include "mb/pg_wchar.h"
#include "pg_getopt.h"
static void
@@ -325,6 +326,8 @@ main(int argc, char *argv[])
(ControlFile->float8ByVal ? _("by value") : _("by reference")));
printf(_("Data page checksum version: %u\n"),
ControlFile->data_checksum_version);
+ printf(_("Shared catalog encoding: %d\n"),
+ ControlFile->shared_catalog_encoding);
printf(_("Mock authentication nonce: %s\n"),
mock_auth_nonce_str);
return 0;
diff --git a/src/bin/pg_upgrade/pg_upgrade.c b/src/bin/pg_upgrade/pg_upgrade.c
index 663235816f8..72d9b1d5a39 100644
--- a/src/bin/pg_upgrade/pg_upgrade.c
+++ b/src/bin/pg_upgrade/pg_upgrade.c
@@ -467,6 +467,25 @@ set_locale_and_encoding(void)
PQfreemem(datctype_literal);
PQfreemem(datlocale_literal);
+ /*
+ * Set the shared catalog encoding to UNKNOWN, because we have to tolerate
+ * multi-encoding source clusters that didn't adhere to our new rules about
+ * non-ASCII in database/role/etc names.
+ *
+ * TODO: for source >= 18, here we should just copy the source's cat
+ * encoding instead.
+ *
+ * TODO: for source < 18, we should start here with UNKNOWN, and then at
+ * end try to change it to template0's encoding or SQL_ASCII in some order
+ * (which?), to see if the validation passes. We'd gradually and
+ * automatically upgrade the world's clusters to defined shared catalog
+ * encoding. Or at least the easy cases that already conform to our new
+ * rules, anyway. The rest would have to do manual work to escape from
+ * UNKNOWN.
+ */
+ PQclear(executeQueryOrDie(conn_new_template1,
+ "ALTER SYSTEM CATALOG ENCODING UNKNOWN"));
+
PQfinish(conn_new_template1);
check_ok();
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index bbd08770c3d..2d1fc4a483b 100644
--- a/src/bin/psql/tab-complete.in.c
+++ b/src/bin/psql/tab-complete.in.c
@@ -1009,6 +1009,13 @@ static const SchemaQuery Query_for_trigger_of_table = {
" FROM pg_catalog.pg_conversion "\
" WHERE pg_catalog.pg_encoding_to_char(conforencoding) LIKE pg_catalog.upper('%s')"
+#define Query_for_list_of_catalog_encodings \
+"SELECT 'SQL_ASCII' "\
+" UNION ALL "\
+"SELECT pg_catalog.getdatabaseencoding() "\
+" UNION ALL "\
+"SELECT 'UNKNOWN'"
+
#define Query_for_list_of_languages \
"SELECT lanname "\
" FROM pg_catalog.pg_language "\
@@ -2550,7 +2557,9 @@ match_previous_words(int pattern_id,
COMPLETE_WITH("OPTIONS");
/* ALTER SYSTEM SET, RESET, RESET ALL */
else if (Matches("ALTER", "SYSTEM"))
- COMPLETE_WITH("SET", "RESET");
+ COMPLETE_WITH("SET", "RESET", "CATALOG ENCODING");
+ else if (Matches("ALTER", "SYSTEM", "CATALOG", "ENCODING"))
+ COMPLETE_WITH_QUERY_VERBATIM(Query_for_list_of_catalog_encodings);
else if (Matches("ALTER", "SYSTEM", "SET|RESET"))
COMPLETE_WITH_QUERY_VERBATIM_PLUS(Query_for_list_of_alter_system_set_vars,
"ALL");
diff --git a/src/bin/scripts/t/020_createdb.pl b/src/bin/scripts/t/020_createdb.pl
index 4a0e2c883a1..f68b7d56cf7 100644
--- a/src/bin/scripts/t/020_createdb.pl
+++ b/src/bin/scripts/t/020_createdb.pl
@@ -12,8 +12,10 @@ program_help_ok('createdb');
program_version_ok('createdb');
program_options_handling_ok('createdb');
+# Because we're using different encodings in the same cluster, we need shared
+# catalog encoding set to SQL_ASCII for this test.
my $node = PostgreSQL::Test::Cluster->new('main');
-$node->init;
+$node->init(extra => [ '--catalog-encoding=SQL_ASCII' ]);
$node->start;
$node->issues_sql_like(
diff --git a/src/include/access/xlog.h b/src/include/access/xlog.h
index 34ad46c067b..39e0325b35a 100644
--- a/src/include/access/xlog.h
+++ b/src/include/access/xlog.h
@@ -234,7 +234,8 @@ extern bool DataChecksumsEnabled(void);
extern XLogRecPtr GetFakeLSNForUnloggedRel(void);
extern Size XLOGShmemSize(void);
extern void XLOGShmemInit(void);
-extern void BootStrapXLOG(uint32 data_checksum_version);
+extern void BootStrapXLOG(int shared_catalog_encoding,
+ uint32 data_checksum_version);
extern void InitializeWalConsistencyChecking(void);
extern void LocalProcessControlFile(bool reset);
extern WalLevel GetActiveWalLevelOnStandby(void);
@@ -253,6 +254,8 @@ extern XLogRecPtr GetFlushRecPtr(TimeLineID *insertTLI);
extern TimeLineID GetWALInsertionTimeLine(void);
extern TimeLineID GetWALInsertionTimeLineIfSet(void);
extern XLogRecPtr GetLastImportantRecPtr(void);
+extern int GetSharedCatalogEncoding(void);
+extern void SetSharedCatalogEncoding(int encoding);
extern void SetWalWriterSleeping(bool sleeping);
diff --git a/src/include/access/xlog_internal.h b/src/include/access/xlog_internal.h
index d9cf51a0f9f..bf4075e3886 100644
--- a/src/include/access/xlog_internal.h
+++ b/src/include/access/xlog_internal.h
@@ -305,6 +305,12 @@ typedef struct xl_end_of_recovery
int wal_level;
} xl_end_of_recovery;
+/* Change to the encoding of shared catalogs. */
+typedef struct xl_catalog_encoding_change
+{
+ int encoding;
+} xl_catalog_encoding_change;
+
/*
* The functions in xloginsert.c construct a chain of XLogRecData structs
* to represent the final WAL record.
diff --git a/src/include/catalog/catalog.h b/src/include/catalog/catalog.h
index a8dd304b1ad..36a0e1625b1 100644
--- a/src/include/catalog/catalog.h
+++ b/src/include/catalog/catalog.h
@@ -43,5 +43,7 @@ extern Oid GetNewOidWithIndex(Relation relation, Oid indexId,
extern RelFileNumber GetNewRelFileNumber(Oid reltablespace,
Relation pg_class,
char relpersistence);
+extern void ValidateSharedCatalogString(Relation rel, const char *s);
+extern void AlterSystemCatalogEncoding(const char *encoding_name);
#endif /* CATALOG_H */
diff --git a/src/include/catalog/pg_control.h b/src/include/catalog/pg_control.h
index e80ff8e4140..b21af726c5b 100644
--- a/src/include/catalog/pg_control.h
+++ b/src/include/catalog/pg_control.h
@@ -77,7 +77,7 @@ typedef struct CheckPoint
#define XLOG_END_OF_RECOVERY 0x90
#define XLOG_FPI_FOR_HINT 0xA0
#define XLOG_FPI 0xB0
-/* 0xC0 is used in Postgres 9.5-11 */
+#define XLOG_CATALOG_ENCODING_CHANGE 0xC0
#define XLOG_OVERWRITE_CONTRECORD 0xD0
#define XLOG_CHECKPOINT_REDO 0xE0
@@ -221,6 +221,9 @@ typedef struct ControlFileData
/* Are data pages protected by checksums? Zero if no checksum version */
uint32 data_checksum_version;
+ /* A pg_enc value, or -1 for UNKNOWN. */
+ int shared_catalog_encoding;
+
/*
* Random nonce, used in authentication requests that need to proceed
* based on values that are cluster-unique, like a SASL exchange that
diff --git a/src/include/commands/alter.h b/src/include/commands/alter.h
index f00af75beff..295d6726ebc 100644
--- a/src/include/commands/alter.h
+++ b/src/include/commands/alter.h
@@ -31,4 +31,6 @@ extern ObjectAddress ExecAlterOwnerStmt(AlterOwnerStmt *stmt);
extern void AlterObjectOwner_internal(Oid classId, Oid objectId,
Oid new_ownerId);
+extern void AlterSystem(AlterSystemStmt *stmt);
+
#endif /* ALTER_H */
diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h
index 0f9462493e3..5698783571f 100644
--- a/src/include/nodes/parsenodes.h
+++ b/src/include/nodes/parsenodes.h
@@ -3841,6 +3841,7 @@ typedef struct AlterSystemStmt
{
NodeTag type;
VariableSetStmt *setstmt; /* SET subcommand */
+ const char *encoding_name; /* CATALOG ENCODING subcommand */
} AlterSystemStmt;
/* ----------------------
diff --git a/src/test/regress/expected/catalog_encoding.out b/src/test/regress/expected/catalog_encoding.out
new file mode 100644
index 00000000000..4ccc1e69325
--- /dev/null
+++ b/src/test/regress/expected/catalog_encoding.out
@@ -0,0 +1,171 @@
+SELECT getdatabaseencoding() <> 'UTF8' AS skip_test \gset
+\if :skip_test
+\quit
+\endif
+-- Check that we are blocked from putting non-ASCII into the shared
+-- catalogs by all known routes, when the encoding is SQL_ASCII. This
+-- exercises the ValidateSharedCatalogString() calls that should cover
+-- all entry points.
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+-- pg_authid
+CREATE USER regress_astérix;
+ERROR: the string "regress_astérix" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+CREATE USER regress_fred;
+ALTER USER regress_fred RENAME TO regress_astérix;
+ERROR: the string "regress_astérix" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+DROP USER regress_fred;
+-- pg_database
+CREATE DATABASE regression_café;
+ERROR: the string "regression_café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+ALTER DATABASE template1 RENAME TO regression_café;
+ERROR: the string "regression_café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+CREATE DATABASE regression_ok TEMPLATE template0 LOCALE 'français';
+WARNING: locale name "français" contains non-ASCII characters
+ERROR: invalid LC_COLLATE locale name: "français"
+HINT: If the locale name is specific to ICU, use ICU_LOCALE.
+-- pg_db_role_setting
+CREATE USER regress_fred;
+ALTER ROLE regress_fred SET application_name TO 'café';
+ERROR: the string "café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+DROP USER regress_fred;
+-- pg_parameter_acl
+-- XXX
+-- pg_replication_origin
+SELECT pg_replication_origin_create('regress_café');
+ERROR: the string "regress_café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+-- pg_shdescription
+COMMENT ON DATABASE template0 IS 'café';
+ERROR: the string "café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+-- non-shared objects are OK, because non-shared catalog
+COMMENT ON TABLE pg_catalog.pg_class IS 'café';
+COMMENT ON TABLE pg_catalog.pg_class IS NULL;
+-- pg_shseclabel
+-- XXX
+-- pg_subscription
+CREATE SUBSCRIPTION regress_café CONNECTION 'dbname=crême' PUBLICATION brûlée;
+ERROR: the string "regress_café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=crême' PUBLICATION brûlée;
+ERROR: the string "dbname=crême" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION brûlée;
+ERROR: the string "brûlée" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION ok WITH (slot_name = 'café');
+ERROR: replication slot name "café" contains invalid character
+HINT: Replication slot names may only contain lower case letters, numbers, and the underscore character.
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION ok WITH (synchronous_commit = 'café');
+ERROR: invalid value for parameter "synchronous_commit": "café"
+HINT: Available values: local, remote_write, remote_apply, on, off.
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION ok WITH (origin = 'café');
+ERROR: unrecognized origin value: "café"
+-- pg_tablespace
+SET allow_in_place_tablespaces = 'on';
+CREATE TABLESPACE regress_café LOCATION '';
+ERROR: the string "regress_café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+CREATE TABLESPACE regress_ok LOCATION '';
+ALTER TABLESPACE regress_ok RENAME TO regress_café;
+ERROR: the string "regress_café" contains characters that cannot be represented in SQL_ASCII
+HINT: Consider ALTER SYSTEM CATALOG ENCODING UTF8.
+DROP TABLESPACE regress_ok;
+-- Check that we can create a new database with a different encoding,
+-- while the shared catalog encoding is SQL_ASCII
+CREATE DATABASE regression_latin1 TEMPLATE template0 LOCALE 'C' ENCODING 'LATIN1';
+-- Check that we can't change the shared catalog encoding to UTF8, becaus that
+-- LATIN1 database is in the way, then drop it so we can.
+ALTER SYSTEM CATALOG ENCODING UTF8;
+ERROR: database "regression_latin1" has incompatible encoding LATIN1
+DROP DATABASE regression_latin1;
+ALTER SYSTEM CATALOG ENCODING UTF8;
+-- Test that we can now do each of those things that failed before, and that
+-- those things block us from going back to SQL_ASCII.
+-- pg_authid
+CREATE USER regress_astérix;
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: existing role name "regress_astérix" contains invalid characters
+HINT: Consider ALTER ROLE ... RENAME TO ... using characters valid in SQL_ASCII.
+DROP USER regress_astérix;
+-- pg_database
+CREATE DATABASE regression_café;
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: existing database name "regression_café" contains invalid characters
+HINT: Consider ALTER DATABASE ... RENAME TO ... using characters valid in SQL_ASCII.
+DROP DATABASE regression_café;
+-- but we can't make a LATIN1 database while we have UTF8 catalogs
+CREATE DATABASE regression_latin1 TEMPLATE template0 LOCALE 'C' ENCODING 'LATIN1';
+ERROR: encoding "LATIN1" is not compatible with shared catalog encoding "UTF8"
+HINT: Consider ALTER SYSTEM CATALOG ENCODING SQL_ASCII.
+-- pg_db_role_setting
+CREATE USER regress_fred;
+ALTER ROLE regress_fred SET application_name TO 'café';
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: role "regress_fred" has setting "application_name" with value "café" that contains invalid characters
+HINT: Consider ALTER ROLE ... SET ... TO ... using characters valid in SQL_ASCII.
+DROP USER regress_fred;
+-- pg_parameter_acl
+-- XXX
+-- pg_replication_origin
+SELECT pg_replication_origin_create('regress_café');
+ pg_replication_origin_create
+------------------------------
+ 1
+(1 row)
+
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: replication origin "regress_café" contains invalid characters
+HINT: Consider recreating the replication origin using characters valid in SQL_ASCII.
+SELECT pg_replication_origin_drop('regress_café');
+ pg_replication_origin_drop
+----------------------------
+
+(1 row)
+
+-- pg_shdescription
+COMMENT ON DATABASE template0 IS 'café';
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: comment "café" on a shared database object contains invalid characters
+HINT: Consider COMMENT ON ... IS ... using characters valid in SQL_ASCII.
+COMMENT ON DATABASE template0 IS 'unmodifiable empty database';
+-- pg_shseclabel
+-- XXX
+-- pg_subscription
+-- XXX
+-- pg_tablespace
+CREATE TABLESPACE regress_café LOCATION '';
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: existing tablespace name "regress_café" contains invalid characters
+HINT: Consider ALTER TABLESPACE ... RENAME TO ... using characters valid in SQL_ASCII.
+DROP TABLESPACE regress_café;
+-- We dropped everything that was in the way, so we should be able to go back
+-- to SQL_ASCII now.
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+-- Try out UNKNOWN mode, which is the only way to have a non-ASCII database
+-- name and mutiple encodings at the same time
+ALTER SYSTEM CATALOG ENCODING UNKNOWN;
+CREATE DATABASE regression_café ENCODING UTF8;
+CREATE DATABASE regression_latin1 TEMPLATE template0 LOCALE 'C' ENCODING 'LATIN1';
+-- We can't switch to SQL_ASCII from this state
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: existing database name "regression_café" contains invalid characters
+HINT: Consider ALTER DATABASE ... RENAME TO ... using characters valid in SQL_ASCII.
+-- We also can't switch to UTF8 from this state
+ALTER SYSTEM CATALOG ENCODING UTF8;
+ERROR: database "regression_latin1" has incompatible encoding LATIN1
+-- If we get rid of the LATIN1 database, we can go to UTF8
+DROP DATABASE regression_latin1;
+ALTER SYSTEM CATALOG ENCODING UTF8;
+-- We still can't go back to SQL_ASCII unless we also get rid of the non-ASCII
+-- database name.
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+ERROR: existing database name "regression_café" contains invalid characters
+HINT: Consider ALTER DATABASE ... RENAME TO ... using characters valid in SQL_ASCII.
+DROP DATABASE regression_café;
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
diff --git a/src/test/regress/expected/catalog_encoding_1.out b/src/test/regress/expected/catalog_encoding_1.out
new file mode 100644
index 00000000000..8505c4fa552
--- /dev/null
+++ b/src/test/regress/expected/catalog_encoding_1.out
@@ -0,0 +1,3 @@
+SELECT getdatabaseencoding() <> 'UTF8' AS skip_test \gset
+\if :skip_test
+\quit
diff --git a/src/test/regress/parallel_schedule b/src/test/regress/parallel_schedule
index 81e4222d26a..63de6216408 100644
--- a/src/test/regress/parallel_schedule
+++ b/src/test/regress/parallel_schedule
@@ -83,6 +83,8 @@ test: create_table_like alter_generic alter_operator misc async dbsize merge mis
# collate.linux.utf8 and collate.icu.utf8 tests cannot be run in parallel with each other
test: rules psql psql_crosstab amutils stats_ext collate.linux.utf8 collate.windows.win1252
+test: catalog_encoding
+
# ----------
# Run these alone so they don't run out of parallel workers
# select_parallel depends on create_misc
diff --git a/src/test/regress/sql/catalog_encoding.sql b/src/test/regress/sql/catalog_encoding.sql
new file mode 100644
index 00000000000..08918322f27
--- /dev/null
+++ b/src/test/regress/sql/catalog_encoding.sql
@@ -0,0 +1,138 @@
+SELECT getdatabaseencoding() <> 'UTF8' AS skip_test \gset
+\if :skip_test
+\quit
+\endif
+
+-- Check that we are blocked from putting non-ASCII into the shared
+-- catalogs by all known routes, when the encoding is SQL_ASCII. This
+-- exercises the ValidateSharedCatalogString() calls that should cover
+-- all entry points.
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+
+-- pg_authid
+CREATE USER regress_astérix;
+CREATE USER regress_fred;
+ALTER USER regress_fred RENAME TO regress_astérix;
+DROP USER regress_fred;
+
+-- pg_database
+CREATE DATABASE regression_café;
+ALTER DATABASE template1 RENAME TO regression_café;
+CREATE DATABASE regression_ok TEMPLATE template0 LOCALE 'français';
+
+-- pg_db_role_setting
+CREATE USER regress_fred;
+ALTER ROLE regress_fred SET application_name TO 'café';
+DROP USER regress_fred;
+
+-- pg_parameter_acl
+-- XXX
+
+-- pg_replication_origin
+SELECT pg_replication_origin_create('regress_café');
+
+-- pg_shdescription
+COMMENT ON DATABASE template0 IS 'café';
+-- non-shared objects are OK, because non-shared catalog
+COMMENT ON TABLE pg_catalog.pg_class IS 'café';
+COMMENT ON TABLE pg_catalog.pg_class IS NULL;
+
+-- pg_shseclabel
+-- XXX
+
+-- pg_subscription
+CREATE SUBSCRIPTION regress_café CONNECTION 'dbname=crême' PUBLICATION brûlée;
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=crême' PUBLICATION brûlée;
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION brûlée;
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION ok WITH (slot_name = 'café');
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION ok WITH (synchronous_commit = 'café');
+CREATE SUBSCRIPTION regress_ok CONNECTION 'dbname=ok' PUBLICATION ok WITH (origin = 'café');
+
+-- pg_tablespace
+SET allow_in_place_tablespaces = 'on';
+CREATE TABLESPACE regress_café LOCATION '';
+CREATE TABLESPACE regress_ok LOCATION '';
+ALTER TABLESPACE regress_ok RENAME TO regress_café;
+DROP TABLESPACE regress_ok;
+
+-- Check that we can create a new database with a different encoding,
+-- while the shared catalog encoding is SQL_ASCII
+CREATE DATABASE regression_latin1 TEMPLATE template0 LOCALE 'C' ENCODING 'LATIN1';
+
+-- Check that we can't change the shared catalog encoding to UTF8, becaus that
+-- LATIN1 database is in the way, then drop it so we can.
+ALTER SYSTEM CATALOG ENCODING UTF8;
+DROP DATABASE regression_latin1;
+ALTER SYSTEM CATALOG ENCODING UTF8;
+
+-- Test that we can now do each of those things that failed before, and that
+-- those things block us from going back to SQL_ASCII.
+
+-- pg_authid
+CREATE USER regress_astérix;
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+DROP USER regress_astérix;
+
+-- pg_database
+CREATE DATABASE regression_café;
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+DROP DATABASE regression_café;
+-- but we can't make a LATIN1 database while we have UTF8 catalogs
+CREATE DATABASE regression_latin1 TEMPLATE template0 LOCALE 'C' ENCODING 'LATIN1';
+
+-- pg_db_role_setting
+CREATE USER regress_fred;
+ALTER ROLE regress_fred SET application_name TO 'café';
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+DROP USER regress_fred;
+
+-- pg_parameter_acl
+-- XXX
+
+-- pg_replication_origin
+SELECT pg_replication_origin_create('regress_café');
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+SELECT pg_replication_origin_drop('regress_café');
+
+-- pg_shdescription
+COMMENT ON DATABASE template0 IS 'café';
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+COMMENT ON DATABASE template0 IS 'unmodifiable empty database';
+
+-- pg_shseclabel
+-- XXX
+
+-- pg_subscription
+-- XXX
+
+-- pg_tablespace
+CREATE TABLESPACE regress_café LOCATION '';
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+DROP TABLESPACE regress_café;
+
+-- We dropped everything that was in the way, so we should be able to go back
+-- to SQL_ASCII now.
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+
+-- Try out UNKNOWN mode, which is the only way to have a non-ASCII database
+-- name and mutiple encodings at the same time
+ALTER SYSTEM CATALOG ENCODING UNKNOWN;
+CREATE DATABASE regression_café ENCODING UTF8;
+CREATE DATABASE regression_latin1 TEMPLATE template0 LOCALE 'C' ENCODING 'LATIN1';
+
+-- We can't switch to SQL_ASCII from this state
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+
+-- We also can't switch to UTF8 from this state
+ALTER SYSTEM CATALOG ENCODING UTF8;
+
+-- If we get rid of the LATIN1 database, we can go to UTF8
+DROP DATABASE regression_latin1;
+ALTER SYSTEM CATALOG ENCODING UTF8;
+
+-- We still can't go back to SQL_ASCII unless we also get rid of the non-ASCII
+-- database name.
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+DROP DATABASE regression_café;
+ALTER SYSTEM CATALOG ENCODING SQL_ASCII;
+
diff --git a/src/tools/pgindent/typedefs.list b/src/tools/pgindent/typedefs.list
index b54428b38cd..90e9940a4dd 100644
--- a/src/tools/pgindent/typedefs.list
+++ b/src/tools/pgindent/typedefs.list
@@ -4085,6 +4085,7 @@ xl_btree_split
xl_btree_unlink_page
xl_btree_update
xl_btree_vacuum
+xl_catalog_encoding_change
xl_clog_truncate
xl_commit_ts_truncate
xl_dbase_create_file_copy_rec
--
2.47.0
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
@ 2024-12-02 23:00 ` Bruce Momjian <bruce@momjian.us>
2024-12-02 23:16 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 67+ messages in thread
From: Bruce Momjian @ 2024-12-02 23:00 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Mon, Dec 2, 2024 at 06:39:48PM +1300, Thomas Munro wrote:
> Despite being a really simple idea for adding one new switch that
> really only "stops" things rather than actually doing anything new, it
> finishes up interacting with locking, logging, checkpointing, control
> file, redo, grammar, pg_upgrade (and I see now that pg_dumpall might
> need a similar approach), and I didn't even look at the startup stuff
> you guys were working on that can hopefully benefit from having
> GetSharedCatalogEncoding(). Hopefully the patch has the right sort of
> ideas in some of those places, but obviously it's a rapid prototype so
> might be way off on some of the details. It fails on Windows CI in a
> very minor way that I see how to fix... later. It's enough to try out
> the user experience anyway. Feedback, flames and ideas welcome.
I am concerned we are going to get a lot of complaints about this
restricted change because most people are happily using whatever
encoding they want, and as long as they don't hit the 64-byte limit,
they are fine. Are people going to be happy with this restriction just
to keep 64+-byte identifiers safe?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-02 23:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
@ 2024-12-02 23:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-02 23:37 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-12-02 23:16 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Bruce Momjian <bruce@momjian.us> writes:
> I am concerned we are going to get a lot of complaints about this
> restricted change because most people are happily using whatever
> encoding they want, and as long as they don't hit the 64-byte limit,
> they are fine. Are people going to be happy with this restriction just
> to keep 64+-byte identifiers safe?
That's a remarkably rose-tinted view of the current state of affairs.
Reality is that using multiple encodings in shared catalogs just plain
doesn't work very well. Even something as simple as "select datname
from pg_database" is likely to give garbage if there are entries in
encodings that don't match your current database's encoding. What
Thomas is proposing is to formalize and then enforce the two usage
patterns that we know work okay.
Moreover, the proposal also includes a third backwards-compatibility
mode that will let anyone who does like the current approach to keep
using it. So I'm unclear on why you think there's a big downside.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-02 23:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-12-02 23:16 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-12-02 23:37 ` Bruce Momjian <bruce@momjian.us>
2024-12-03 01:41 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Bruce Momjian @ 2024-12-02 23:37 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Mon, Dec 2, 2024 at 06:16:19PM -0500, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > I am concerned we are going to get a lot of complaints about this
> > restricted change because most people are happily using whatever
> > encoding they want, and as long as they don't hit the 64-byte limit,
> > they are fine. Are people going to be happy with this restriction just
> > to keep 64+-byte identifiers safe?
>
> That's a remarkably rose-tinted view of the current state of affairs.
> Reality is that using multiple encodings in shared catalogs just plain
> doesn't work very well. Even something as simple as "select datname
> from pg_database" is likely to give garbage if there are entries in
> encodings that don't match your current database's encoding. What
> Thomas is proposing is to formalize and then enforce the two usage
> patterns that we know work okay.
>
> Moreover, the proposal also includes a third backwards-compatibility
> mode that will let anyone who does like the current approach to keep
> using it. So I'm unclear on why you think there's a big downside.
I have not heard of anyone complaining about the problem of viewing the
shared catalog columns so I didn't consider that benefit.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-02 23:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-12-02 23:16 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-12-02 23:37 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
@ 2024-12-03 01:41 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 67+ messages in thread
From: Tom Lane @ 2024-12-03 01:41 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Bruce Momjian <bruce@momjian.us> writes:
> On Mon, Dec 2, 2024 at 06:16:19PM -0500, Tom Lane wrote:
>> Reality is that using multiple encodings in shared catalogs just plain
>> doesn't work very well. Even something as simple as "select datname
>> from pg_database" is likely to give garbage if there are entries in
>> encodings that don't match your current database's encoding. What
>> Thomas is proposing is to formalize and then enforce the two usage
>> patterns that we know work okay.
> I have not heard of anyone complaining about the problem of viewing the
> shared catalog columns so I didn't consider that benefit.
That's probably because they've learned the hard way to use one of
the two usage patterns that actually work.
Also, I think we have some code around pg_stat_activity that
suppresses possibly-wrongly-encoded data from other DBs (in query
text, not only user/DB names). That suppression could be relaxed
in the only-one-encoding mode, which would be a genuinue benefit.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
@ 2024-12-03 07:38 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-03 08:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
1 sibling, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-12-03 07:38 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Nathan Bossart <nathandbossart@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Mon, Dec 02, 2024 at 06:39:48PM +1300, Thomas Munro wrote:
> On Fri, Nov 29, 2024 at 11:15 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> > hm, are you saying that when choosing PG_SQL_ASCII to represent Mode 2
> > (ASCII-only with validation) in the shared_catalog_encoding field,
> > we're giving it a different semantic meaning than it has elsewhere in the
> > system? Maybe we could just document very clearly that its meaning in
> > shared_catalog_encoding is special/different?
>
> Documentation seems enough to me. Unless you think it would be useful
> outside this use case?
No, I also think that documentation update should be enough.
> Hmm, in theory I suppose validated ASCII7 would be the ideal encoding
> for template0, or generally any template that is allowed to be cloned
> into a new database with a different encoding. It would enforce
> something that is just a promise or convention today.
I agree since all ASCII7 characters should be valid in the other encoding.
> I don't think
> that is really a pressing issue in itself, the convention holds up
> pretty well, but it's conceptually quite closely related, so it's at
> least interesting to think about. I dunno.
Yeah, while it's true that SQL_ASCII is more like "no encoding" (no validation
and allows any byte sequence), I also don't think there is pressure to enforce
"real" ASCII7 for template0.
> > > $ CREATE ROLE lætitia;
> > > ERROR: role name "lætitia" cannot be represented in the shared catalog
> > > encoding SQL_ASCII
> > > HINT: To allow non-ASCII roles, shared_catalog_encoding must be set to
> > > an encoding matching all databases (or UNKNOWN, not recommended)
> >
> > That would sound reasonable to me.
>
> Cool. You're both telling me this sounds worth trying out, so I
> hacked up a proof-of-concept. Please see attached.
Thanks for the patch!
> Almost half of the patch is tedious validation code that knows where
> all the strings are hiding in the shared catalogs (and TODOs remain).
> I wonder if that part could be automated somehow with schema analysis.
> On the other hand, that stuff is not changing in a hurry, and you get
> to write friendly actionable messages if you do it manually, for
I also think the user experience is important here (better error messages) over
maintenance simplicity (automated schema analysis).
Maybe we can try an "hybrid" approach that could simplify the AlterSystemCatalogEncoding()
by relying on a new struct, say:
"
typedef struct {
Oid relationId;
const char *relationName;
struct {
AttrNumber attrNum;
bool isName;
const char *fieldDesc;
const char *hintMsg;
} attrs[4];
} CatalogValidationDef;
"
And then let the validation iterates over an array of CatalogValidationDef?
"
static const CatalogValidationDef validationDefs[] = {
{
AuthIdRelationId,
"role",
{{Anum_pg_authid_rolname, true, "name",
"Consider ALTER ROLE ... RENAME TO ... using characters valid in SQL_ASCII."}}
},
.
.
"
And use schema analysis "only" to verify completeness (catch missing fields)?
> I'm on the fence about the default. Here I defaulted to
> single-encoding, figuring that multi-encoding clusters are possibly a
> fairly advanced configuration and that that user group could just run
> one extra command, and there's even a HINT.
I think that makes sense. It makes the default "simple" and the complex case
possible considering multi-encoding an advanced configuration.
> Despite being a really simple idea for adding one new switch that
> really only "stops" things rather than actually doing anything new, it
> finishes up interacting with locking, logging, checkpointing, control
> file, redo, grammar, pg_upgrade (and I see now that pg_dumpall might
> need a similar approach),
Yeah, indeed the impact is not negligible and that's probably one more reason
to "just" keep the "only stops" behavior.
> and I didn't even look at the startup stuff
> you guys were working on that can hopefully benefit from having
> GetSharedCatalogEncoding(). Hopefully the patch has the right sort of
> ideas in some of those places, but obviously it's a rapid prototype so
> might be way off on some of the details.
I'll look more in details in the near future (unless someone has cons about your
suggested approach, which is not my case).
Do you think it's worth to move the discussion into a dedicated hackers thread?
(maybe reaching a wider audience?) I think the subject is sensible enough.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-03 07:38 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-12-03 08:03 ` Thomas Munro <thomas.munro@gmail.com>
2024-12-11 20:59 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Thomas Munro @ 2024-12-03 08:03 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Nathan Bossart <nathandbossart@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Tue, Dec 3, 2024 at 8:38 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> Maybe we can try an "hybrid" approach that could simplify the AlterSystemCatalogEncoding()
> by relying on a new struct, say:
Interesting idea, yeah, I'll look into that.
> Do you think it's worth to move the discussion into a dedicated hackers thread?
> (maybe reaching a wider audience?) I think the subject is sensible enough.
Ok yeah, I'll start a new thread on -hackers soon.
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-03 07:38 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-03 08:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
@ 2024-12-11 20:59 ` Nathan Bossart <nathandbossart@gmail.com>
2024-12-11 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-12-11 22:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
0 siblings, 2 replies; 67+ messages in thread
From: Nathan Bossart @ 2024-12-11 20:59 UTC (permalink / raw)
To: Thomas Munro <thomas.munro@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Tue, Dec 03, 2024 at 09:03:55PM +1300, Thomas Munro wrote:
> On Tue, Dec 3, 2024 at 8:38 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
>> Maybe we can try an "hybrid" approach that could simplify the AlterSystemCatalogEncoding()
>> by relying on a new struct, say:
>
> Interesting idea, yeah, I'll look into that.
>
>> Do you think it's worth to move the discussion into a dedicated hackers thread?
>> (maybe reaching a wider audience?) I think the subject is sensible enough.
>
> Ok yeah, I'll start a new thread on -hackers soon.
If we are leaning towards a more comprehensive fix in v18, ISTM we should
go ahead and revert commit 562bee0 (both for master and v17). Or am I
misinterpreting the proposed path forward here?
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-03 07:38 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-03 08:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-11 20:59 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-12-11 21:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-12 21:55 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
1 sibling, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-12-11 21:12 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> If we are leaning towards a more comprehensive fix in v18, ISTM we should
> go ahead and revert commit 562bee0 (both for master and v17). Or am I
> misinterpreting the proposed path forward here?
That seems like a reasonable thing to do now, since we have a
complaint about v17's behavior and there seems no compelling
reason why v17 has to address this ancient issue.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-03 07:38 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-03 08:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-11 20:59 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-12-11 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-12-12 21:55 ` Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 0 replies; 67+ messages in thread
From: Nathan Bossart @ 2024-12-12 21:55 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Thomas Munro <thomas.munro@gmail.com>; Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Dec 11, 2024 at 04:12:46PM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
>> If we are leaning towards a more comprehensive fix in v18, ISTM we should
>> go ahead and revert commit 562bee0 (both for master and v17). Or am I
>> misinterpreting the proposed path forward here?
>
> That seems like a reasonable thing to do now, since we have a
> complaint about v17's behavior and there seems no compelling
> reason why v17 has to address this ancient issue.
Done. Thanks all for the discussion.
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 12:22 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-03 07:38 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-03 08:03 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Thomas Munro <thomas.munro@gmail.com>
2024-12-11 20:59 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-12-11 22:39 ` Thomas Munro <thomas.munro@gmail.com>
1 sibling, 0 replies; 67+ messages in thread
From: Thomas Munro @ 2024-12-11 22:39 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Dec 12, 2024 at 9:59 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> If we are leaning towards a more comprehensive fix in v18, ISTM we should
> go ahead and revert commit 562bee0 (both for master and v17). Or am I
> misinterpreting the proposed path forward here?
Yeah. Just to confirm, the CLUSTER ENCODING concept is definitely
future-release-only material
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-23 08:37 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-23 09:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2 siblings, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-23 08:37 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Fri, Nov 22, 2024 at 02:01:41PM -0600, Nathan Bossart wrote:
> On Fri, Nov 22, 2024 at 02:23:47PM -0500, Tom Lane wrote:
> > After more thought I don't really like the idea of failing if there
> > are multiple matches. It means that we might fail in cases where
> > pre-v17 worked fine (because NAMEDATALEN-1 was accidentally the
> > right truncation point). ISTM the entire point of this patch is to
> > restore the pre-v17 behavior as much as possible, so that seems like
> > the wrong outcome.
>
> That's fine with me.
+1
> > So that means we could do something like the attached. (There's
> > room for argument about which error messages in InitPostgres
> > should use in_dbname versus the truncated name, but I chose to
> > use in_dbname for the two "does not exist" reports.)
>
> Looks reasonable to me. I had been thinking of ways to simplify this code
> based on Bruce's feedback, and I came up with the attached. If nothing
> else, this at least helps minimize the amount of code that is only reached
> in extremely rare cases, but it's probably not quite as performant as v4
> for the usual path, so v4 may still be the way to go.
Yeah, so what about v6 attached ("mixing" v4 and v5 by using a fast path in
case the name is short enough).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachments:
v6-attempt-multibyte-aware-truncation.patch (text/x-diff, 4.7K) download
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 5b657a3f13..f39f3dec8a 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -68,6 +68,7 @@
#include "utils/timeout.h"
static HeapTuple GetDatabaseTuple(const char *dbname);
+static HeapTuple GetDatabaseTupleInternal(Relation relation, const char *dbname);
static HeapTuple GetDatabaseTupleByOid(Oid dboid);
static void PerformAuthentication(Port *port);
static void CheckMyDatabase(const char *name, bool am_superuser, bool override_allow_connections);
@@ -97,12 +98,75 @@ static void process_settings(Oid databaseid, Oid roleid);
* descriptors for both pg_database and its indexes from the shared relcache
* cache file, and so we can do an indexscan. criticalSharedRelcachesBuilt
* tells whether we got the cached descriptors.
+ *
+ * This function also deals with the trickier-than-it-sounds issue of
+ * truncating an overlength incoming database name. We do not know which
+ * encoding the name is in, so we can't apply pg_encoding_mbcliplen() as
+ * CREATE DATABASE would have done. We use the heuristic of truncating one
+ * byte at a time until we find a match in pg_database, relying on the
+ * assumption that the name as stored in pg_database is valid according to
+ * some server-side encoding. This lets us constrain the search using the
+ * fact that all bytes of a multibyte character have their high bit set.
*/
static HeapTuple
GetDatabaseTuple(const char *dbname)
{
- HeapTuple tuple;
+ HeapTuple tuple = NULL;
Relation relation;
+ char tname[NAMEDATALEN];
+
+ relation = table_open(DatabaseRelationId, AccessShareLock);
+
+ /* Fast path if name is short enough, use it directly */
+ if (strlen(dbname) < NAMEDATALEN) {
+ tuple = GetDatabaseTupleInternal(relation, dbname);
+
+ if (HeapTupleIsValid(tuple)) {
+ table_close(relation, AccessShareLock);
+ return tuple;
+ }
+ }
+
+ /* Need to try truncation */
+ for (int i = NAMEDATALEN - 1;
+ i >= NAMEDATALEN - MAX_MULTIBYTE_CHAR_LEN;
+ i--)
+ {
+ strncpy(tname, dbname, sizeof(tname));
+ tname[i] = '\0';
+
+ /*
+ * Take the first match. It's theoretically possible that we could
+ * find more than one match if we continued to try shorter truncations
+ * (which is what makes this a heuristic). This is unlikely though.
+ * We considered failing if there are multiple candidate matches, but
+ * that cure seems worse than the disease: it might reject cases that
+ * worked fine before v17.
+ */
+ tuple = GetDatabaseTupleInternal(relation, tname);
+ if (HeapTupleIsValid(tuple))
+ break;
+
+ /*
+ * If the bytes at the truncation point are ASCII characters, we know
+ * that they cannot both be part of the same character, so the
+ * original truncation by CREATE/ALTER DATABASE would have gone no
+ * further.
+ */
+ if (!IS_HIGHBIT_SET(dbname[i]) || !IS_HIGHBIT_SET(dbname[i - 1]))
+ break;
+ }
+
+ table_close(relation, AccessShareLock);
+
+ return tuple;
+}
+
+/* One tuple fetch for GetDatabaseTuple */
+static HeapTuple
+GetDatabaseTupleInternal(Relation relation, const char *dbname)
+{
+ HeapTuple tuple;
SysScanDesc scan;
ScanKeyData key[1];
@@ -115,11 +179,10 @@ GetDatabaseTuple(const char *dbname)
CStringGetDatum(dbname));
/*
- * Open pg_database and fetch a tuple. Force heap scan if we haven't yet
- * built the critical shared relcache entries (i.e., we're starting up
- * without a shared relcache cache file).
+ * Try to fetch the tuple. Force heap scan if we haven't yet built the
+ * critical shared relcache entries (i.e., we're starting up without a
+ * shared relcache cache file).
*/
- relation = table_open(DatabaseRelationId, AccessShareLock);
scan = systable_beginscan(relation, DatabaseNameIndexId,
criticalSharedRelcachesBuilt,
NULL,
@@ -133,7 +196,6 @@ GetDatabaseTuple(const char *dbname)
/* all done */
systable_endscan(scan);
- table_close(relation, AccessShareLock);
return tuple;
}
@@ -1011,6 +1073,8 @@ InitPostgres(const char *in_dbname, Oid dboid,
errmsg("database \"%s\" does not exist", in_dbname)));
dbform = (Form_pg_database) GETSTRUCT(tuple);
dboid = dbform->oid;
+ /* Save the real (possibly truncated) database name */
+ strlcpy(dbname, NameStr(dbform->datname), sizeof(dbname));
}
else if (!OidIsValid(dboid))
{
@@ -1066,8 +1130,9 @@ InitPostgres(const char *in_dbname, Oid dboid,
if (HeapTupleIsValid(tuple))
datform = (Form_pg_database) GETSTRUCT(tuple);
+ /* Note comparison here must be against the truncated DB name */
if (!HeapTupleIsValid(tuple) ||
- (in_dbname && namestrcmp(&datform->datname, in_dbname)))
+ (in_dbname && namestrcmp(&datform->datname, dbname) != 0))
{
if (in_dbname)
ereport(FATAL,
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-23 08:37 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-23 09:50 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 0 replies; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-23 09:50 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Bruce Momjian <bruce@momjian.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Sat, Nov 23, 2024 at 08:37:18AM +0000, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Nov 22, 2024 at 02:01:41PM -0600, Nathan Bossart wrote:
> > On Fri, Nov 22, 2024 at 02:23:47PM -0500, Tom Lane wrote:
> > > After more thought I don't really like the idea of failing if there
> > > are multiple matches. It means that we might fail in cases where
> > > pre-v17 worked fine (because NAMEDATALEN-1 was accidentally the
> > > right truncation point). ISTM the entire point of this patch is to
> > > restore the pre-v17 behavior as much as possible, so that seems like
> > > the wrong outcome.
> >
> > That's fine with me.
>
> +1
>
> > > So that means we could do something like the attached. (There's
> > > room for argument about which error messages in InitPostgres
> > > should use in_dbname versus the truncated name, but I chose to
> > > use in_dbname for the two "does not exist" reports.)
> >
> > Looks reasonable to me. I had been thinking of ways to simplify this code
> > based on Bruce's feedback, and I came up with the attached. If nothing
> > else, this at least helps minimize the amount of code that is only reached
> > in extremely rare cases, but it's probably not quite as performant as v4
> > for the usual path, so v4 may still be the way to go.
>
> Yeah, so what about v6 attached ("mixing" v4 and v5 by using a fast path in
> case the name is short enough).
v7 attach is even better than v6.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachments:
v7-attempt-multibyte-aware-truncation.patch (text/x-diff, 4.7K) download
diff --git a/src/backend/utils/init/postinit.c b/src/backend/utils/init/postinit.c
index 5b657a3f13..2669332f45 100644
--- a/src/backend/utils/init/postinit.c
+++ b/src/backend/utils/init/postinit.c
@@ -68,6 +68,7 @@
#include "utils/timeout.h"
static HeapTuple GetDatabaseTuple(const char *dbname);
+static HeapTuple GetDatabaseTupleInternal(Relation relation, const char *dbname);
static HeapTuple GetDatabaseTupleByOid(Oid dboid);
static void PerformAuthentication(Port *port);
static void CheckMyDatabase(const char *name, bool am_superuser, bool override_allow_connections);
@@ -97,12 +98,72 @@ static void process_settings(Oid databaseid, Oid roleid);
* descriptors for both pg_database and its indexes from the shared relcache
* cache file, and so we can do an indexscan. criticalSharedRelcachesBuilt
* tells whether we got the cached descriptors.
+ *
+ * This function also deals with the trickier-than-it-sounds issue of
+ * truncating an overlength incoming database name. We do not know which
+ * encoding the name is in, so we can't apply pg_encoding_mbcliplen() as
+ * CREATE DATABASE would have done. We use the heuristic of truncating one
+ * byte at a time until we find a match in pg_database, relying on the
+ * assumption that the name as stored in pg_database is valid according to
+ * some server-side encoding. This lets us constrain the search using the
+ * fact that all bytes of a multibyte character have their high bit set.
*/
static HeapTuple
GetDatabaseTuple(const char *dbname)
{
- HeapTuple tuple;
+ HeapTuple tuple = NULL;
Relation relation;
+ char tname[NAMEDATALEN];
+
+ relation = table_open(DatabaseRelationId, AccessShareLock);
+
+ /* Fast path if name is short enough, use it directly */
+ if (strlen(dbname) < NAMEDATALEN) {
+ tuple = GetDatabaseTupleInternal(relation, dbname);
+ table_close(relation, AccessShareLock);
+ return tuple;
+ }
+
+ /* Need to try truncation */
+ for (int i = NAMEDATALEN - 1;
+ i >= NAMEDATALEN - MAX_MULTIBYTE_CHAR_LEN;
+ i--)
+ {
+ strncpy(tname, dbname, sizeof(tname));
+ tname[i] = '\0';
+
+ /*
+ * Take the first match. It's theoretically possible that we could
+ * find more than one match if we continued to try shorter truncations
+ * (which is what makes this a heuristic). This is unlikely though.
+ * We considered failing if there are multiple candidate matches, but
+ * that cure seems worse than the disease: it might reject cases that
+ * worked fine before v17.
+ */
+ tuple = GetDatabaseTupleInternal(relation, tname);
+ if (HeapTupleIsValid(tuple))
+ break;
+
+ /*
+ * If the bytes at the truncation point are ASCII characters, we know
+ * that they cannot both be part of the same character, so the
+ * original truncation by CREATE/ALTER DATABASE would have gone no
+ * further.
+ */
+ if (!IS_HIGHBIT_SET(dbname[i]) || !IS_HIGHBIT_SET(dbname[i - 1]))
+ break;
+ }
+
+ table_close(relation, AccessShareLock);
+
+ return tuple;
+}
+
+/* One tuple fetch for GetDatabaseTuple */
+static HeapTuple
+GetDatabaseTupleInternal(Relation relation, const char *dbname)
+{
+ HeapTuple tuple;
SysScanDesc scan;
ScanKeyData key[1];
@@ -115,11 +176,10 @@ GetDatabaseTuple(const char *dbname)
CStringGetDatum(dbname));
/*
- * Open pg_database and fetch a tuple. Force heap scan if we haven't yet
- * built the critical shared relcache entries (i.e., we're starting up
- * without a shared relcache cache file).
+ * Try to fetch the tuple. Force heap scan if we haven't yet built the
+ * critical shared relcache entries (i.e., we're starting up without a
+ * shared relcache cache file).
*/
- relation = table_open(DatabaseRelationId, AccessShareLock);
scan = systable_beginscan(relation, DatabaseNameIndexId,
criticalSharedRelcachesBuilt,
NULL,
@@ -133,7 +193,6 @@ GetDatabaseTuple(const char *dbname)
/* all done */
systable_endscan(scan);
- table_close(relation, AccessShareLock);
return tuple;
}
@@ -1011,6 +1070,8 @@ InitPostgres(const char *in_dbname, Oid dboid,
errmsg("database \"%s\" does not exist", in_dbname)));
dbform = (Form_pg_database) GETSTRUCT(tuple);
dboid = dbform->oid;
+ /* Save the real (possibly truncated) database name */
+ strlcpy(dbname, NameStr(dbform->datname), sizeof(dbname));
}
else if (!OidIsValid(dboid))
{
@@ -1066,8 +1127,9 @@ InitPostgres(const char *in_dbname, Oid dboid,
if (HeapTupleIsValid(tuple))
datform = (Form_pg_database) GETSTRUCT(tuple);
+ /* Note comparison here must be against the truncated DB name */
if (!HeapTupleIsValid(tuple) ||
- (in_dbname && namestrcmp(&datform->datname, in_dbname)))
+ (in_dbname && namestrcmp(&datform->datname, dbname) != 0))
{
if (in_dbname)
ereport(FATAL,
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-23 17:50 ` Bruce Momjian <bruce@momjian.us>
1 sibling, 0 replies; 67+ messages in thread
From: Bruce Momjian @ 2024-11-23 17:50 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Fri, Nov 22, 2024 at 02:23:47PM -0500, Tom Lane wrote:
> + if (strlen(dbname) < NAMEDATALEN)
> + {
> + /* Typical, easy case: no truncation needed */
> + tuple = GetDatabaseTupleInternal(relation, dbname);
> + }
> + else if (!IS_HIGHBIT_SET(dbname[NAMEDATALEN - 1]) ||
> + !IS_HIGHBIT_SET(dbname[NAMEDATALEN - 2]))
> + {
> + /* Also easy: truncation at NAMEDATALEN - 1 cannot break an MB char */
> + memcpy(tname, dbname, sizeof(tname));
> + tname[NAMEDATALEN - 1] = '\0';
> + tuple = GetDatabaseTupleInternal(relation, tname);
I had some time to think about this issue and I now realize the test
above is correct, but I couldn't figure out why it was correct before.
If we want to use this test, which I now think is fine, I suggest the
following comment:
If we put a NULL byte at byte offset NAMEDATALEN - 1, we don't want
to break a multi-byte character when doing this. If byte offset
NAMEDATALEN - 1 does not have its high bit set, we can be sure
we will not break a multi-byte character during the overwrite.
Also, if NAMEDATALEN - 2 does not have its high bit set, then
NAMEDATALEN - 1 is either a single-byte non-ASCII character,
or is the _start_ of a multi-byte character, so it is also safe
to overwrite it without breaking a multi-byte character.
Sorry I did not figure this out earlier.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bruce Momjian <bruce@momjian.us>
@ 2024-11-22 00:11 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 67+ messages in thread
From: Tom Lane @ 2024-11-22 00:11 UTC (permalink / raw)
To: Bruce Momjian <bruce@momjian.us>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Bruce Momjian <bruce@momjian.us> writes:
> But the logic doesn't make sense. Why would two bytes be any different
> than one? I assumed you would just remove all trailing high-bit bytes
> and stop and the first non-high-bit byte.
To take the most obvious counterexample: what if the name contains
*only* high-bit-set bytes? In any case, this logic must achieve
the same effect as the original encoding-aware truncation, which
will not have removed more than it absolutely had to.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-22 04:39 ` John Naylor <johncnaylorls@gmail.com>
2024-11-22 04:53 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 67+ messages in thread
From: John Naylor @ 2024-11-22 04:39 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Thu, Nov 21, 2024 at 2:27 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
+ /*
+ * If the original name is too long and we see two consecutive bytes
+ * with their high bits set at the truncation point, we might have
+ * truncated in the middle of a multibyte character. In multibyte
+ * encodings, every byte of a multibyte character has its high bit
+ * set.
Counterexample: Shift JIS -- I don't think we can short-circuit the full check.
--
John Naylor
Amazon Web Services
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 04:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails John Naylor <johncnaylorls@gmail.com>
@ 2024-11-22 04:53 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 67+ messages in thread
From: Tom Lane @ 2024-11-22 04:53 UTC (permalink / raw)
To: John Naylor <johncnaylorls@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
John Naylor <johncnaylorls@gmail.com> writes:
> On Thu, Nov 21, 2024 at 2:27 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> + * If the original name is too long and we see two consecutive bytes
> + * with their high bits set at the truncation point, we might have
> + * truncated in the middle of a multibyte character. In multibyte
> + * encodings, every byte of a multibyte character has its high bit
> + * set.
> Counterexample: Shift JIS -- I don't think we can short-circuit the full check.
Shift JIS is not an allowed server-side encoding, for precisely
that reason. This whole proposal is based on the assumption that
the string we need to match in pg_database is valid in some
server-side encoding.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-20 08:17 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:10 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-20 08:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Tue, Nov 19, 2024 at 06:09:44PM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
> > On Tue, Nov 19, 2024 at 02:33:27PM -0500, Tom Lane wrote:
> >> I did think of a way that we could approximate encoding-correct
> >> truncation here, relying on the fact that what's in pg_database
> >> is encoding-correct according to somebody:
> >> ...
>
> > That's an interesting idea. That code would probably need to live in
> > GetDatabaseTuple(), but it seems doable. We might be able to avoid the
> > "mighty improbable" case by always truncating up to
> > MAX_MULTIBYTE_CHAR_LEN-1 times and failing if there are multiple matches,
> > too.
>
> Hmm ... but with short characters (e.g. LATIN1) there might be
> legitimately-different names that that rule would complain about.
Could we rely on pg_encoding_max_length() instead of MAX_MULTIBYTE_CHAR_LEN? That
would then work for short characters too IIUC.
> Also, we could bypass the multiple lookups unless both the
> NAMEDATALEN-1'th and NAMEDATALEN-2'th bytes are non-ASCII, which
> should be rare enough to make it not much of a performance issue.
>
> One annoying point is that we also need this for role lookup.
Yeah. The role existence is checked before the database existence. And even if
that would not be the case, it would make litle sense to rely on the
pg_encoding_max_length() of the matching database for the role, as those are
global.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-20 15:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:20 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-20 15:10 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> Could we rely on pg_encoding_max_length() instead of MAX_MULTIBYTE_CHAR_LEN? That
> would then work for short characters too IIUC.
No. We don't know which encoding it is. Even if you wanted to say
"use the database encoding", we haven't identified the database yet.
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:10 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-20 15:20 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:32 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-20 15:20 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Hi,
On Wed, Nov 20, 2024 at 10:10:51AM -0500, Tom Lane wrote:
> Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
> > Could we rely on pg_encoding_max_length() instead of MAX_MULTIBYTE_CHAR_LEN? That
> > would then work for short characters too IIUC.
>
> No. We don't know which encoding it is. Even if you wanted to say
> "use the database encoding", we haven't identified the database yet.
I had in mind to "fully scan" pg_database in GetDatabaseTuple(), get the datname
and encoding from FormData_pg_database and start from there the comparison
with the dbname passed as an argument to GetDatabaseTuple(). Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:10 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:20 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
@ 2024-11-20 15:32 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 67+ messages in thread
From: Nathan Bossart @ 2024-11-20 15:32 UTC (permalink / raw)
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Nov 20, 2024 at 03:20:45PM +0000, Bertrand Drouvot wrote:
> On Wed, Nov 20, 2024 at 10:10:51AM -0500, Tom Lane wrote:
>> Bertrand Drouvot <bertranddrouvot.pg@gmail.com> writes:
>> > Could we rely on pg_encoding_max_length() instead of MAX_MULTIBYTE_CHAR_LEN? That
>> > would then work for short characters too IIUC.
>>
>> No. We don't know which encoding it is. Even if you wanted to say
>> "use the database encoding", we haven't identified the database yet.
>
> I had in mind to "fully scan" pg_database in GetDatabaseTuple(), get the datname
> and encoding from FormData_pg_database and start from there the comparison
> with the dbname passed as an argument to GetDatabaseTuple(). Thoughts?
I was wondering if we could use the database encoding to disambiguate if we
found multiple matches, but IIUC the identifier will be truncated using the
encoding of the database from which it was created. But hopefully this is
all rare enough in practice...
--
nathan
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:10 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:20 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:32 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
@ 2024-11-20 15:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 1 reply; 67+ messages in thread
From: Tom Lane @ 2024-11-20 15:39 UTC (permalink / raw)
To: Nathan Bossart <nathandbossart@gmail.com>; +Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Nov 20, 2024 at 03:20:45PM +0000, Bertrand Drouvot wrote:
>> I had in mind to "fully scan" pg_database in GetDatabaseTuple(), get the datname
>> and encoding from FormData_pg_database and start from there the comparison
>> with the dbname passed as an argument to GetDatabaseTuple(). Thoughts?
> I was wondering if we could use the database encoding to disambiguate if we
> found multiple matches, but IIUC the identifier will be truncated using the
> encoding of the database from which it was created.
Yeah, you can't really assume that a database's name is stored using
the encoding of that database. And even if you did, you still can't
make any assumptions about pg_role. I doubt we want to do this
differently for roles than databases.
We've had some past discussions about tightening all this up, like
insisting that names in shared catalogs are always in UTF8. But
there are downsides to that too.
In any case, there is no way that a seqscan of pg_database (or
pg_role) is going to be adequately performant, let alone faster
than at-most-four indexed probes. We just had somebody inquiring
about whether it'd be okay to create a million roles...
regards, tom lane
^ permalink raw reply [nested|flat] 67+ messages in thread
* Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:17 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:10 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:20 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:32 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:39 ` Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails Tom Lane <tgl@sss.pgh.pa.us>
@ 2024-11-20 16:02 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
0 siblings, 0 replies; 67+ messages in thread
From: Bertrand Drouvot @ 2024-11-20 16:02 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Nathan Bossart <nathandbossart@gmail.com>; adam@labkey.com; pgsql-bugs@lists.postgresql.org
On Wed, Nov 20, 2024 at 10:39:35AM -0500, Tom Lane wrote:
> Nathan Bossart <nathandbossart@gmail.com> writes:
> > On Wed, Nov 20, 2024 at 03:20:45PM +0000, Bertrand Drouvot wrote:
> >> I had in mind to "fully scan" pg_database in GetDatabaseTuple(), get the datname
> >> and encoding from FormData_pg_database and start from there the comparison
> >> with the dbname passed as an argument to GetDatabaseTuple(). Thoughts?
>
> > I was wondering if we could use the database encoding to disambiguate if we
> > found multiple matches, but IIUC the identifier will be truncated using the
> > encoding of the database from which it was created.
>
> Yeah, you can't really assume that a database's name is stored using
> the encoding of that database.
Yeah, good point, let's stick to the MAX_MULTIBYTE_CHAR_LEN idea then and discard
the usage of pg_encoding_max_length().
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 67+ messages in thread
end of thread, other threads:[~2024-12-12 21:55 UTC | newest]
Thread overview: 67+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-11-16 00:12 BUG #18711: Attempting a connection with a database name longer than 63 characters now fails PG Bug reporting form <noreply@postgresql.org>
2024-11-17 18:00 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 18:48 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 19:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-19 22:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-19 23:09 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 03:47 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 04:23 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:35 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 16:29 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 22:36 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 07:27 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:21 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 14:35 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-21 14:47 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 15:14 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 16:44 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 17:09 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-21 18:05 ` Bruce Momjian <bruce@momjian.us>
2024-11-21 18:14 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 07:45 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-22 19:23 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:01 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:06 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-22 20:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 20:17 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 15:40 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 16:03 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 16:36 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 16:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 17:43 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 17:50 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:03 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-27 18:12 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-27 18:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-27 19:34 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-28 08:12 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-28 12:22 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-28 16:45 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-28 21:12 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-29 10:15 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-02 05:39 ` Thomas Munro <thomas.munro@gmail.com>
2024-12-02 23:00 ` Bruce Momjian <bruce@momjian.us>
2024-12-02 23:16 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-02 23:37 ` Bruce Momjian <bruce@momjian.us>
2024-12-03 01:41 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-03 07:38 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-12-03 08:03 ` Thomas Munro <thomas.munro@gmail.com>
2024-12-11 20:59 ` Nathan Bossart <nathandbossart@gmail.com>
2024-12-11 21:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-12-12 21:55 ` Nathan Bossart <nathandbossart@gmail.com>
2024-12-11 22:39 ` Thomas Munro <thomas.munro@gmail.com>
2024-11-23 08:37 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-23 09:50 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-23 17:50 ` Bruce Momjian <bruce@momjian.us>
2024-11-22 00:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-22 04:39 ` John Naylor <johncnaylorls@gmail.com>
2024-11-22 04:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 08:17 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 15:20 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
2024-11-20 15:32 ` Nathan Bossart <nathandbossart@gmail.com>
2024-11-20 15:39 ` Tom Lane <tgl@sss.pgh.pa.us>
2024-11-20 16:02 ` Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox