From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: adam@labkey.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Date: Thu, 28 Nov 2024 11:45:06 -0500
Message-ID: <2094158.1732812306@sss.pgh.pa.us> (raw)
In-Reply-To: <CA+hUKGKKNAc599Vp7kFAnLE1=V=ceYujz_YQoSNrvNFGaJ6i7w@mail.gmail.com>
References: <Zz9OTyWAvATeeHev@nathan>
<Zz9jfOkVmlYcYHSy@momjian.us>
<Zz9pOi3pGF-DnJTp@nathan>
<Zz92cka2VlBDsat3@momjian.us>
<Zz94l3LHsML0V9eu@nathan>
<Z0A2o+dS0MqDE2Fs@ip-10-97-1-34.eu-west-3.compute.internal>
<659706.1732303427@sss.pgh.pa.us>
<Z0DjJbJV4ZWkLuQd@nathan>
<665338.1732306066@sss.pgh.pa.us>
<Z0Dmw1ryKH8bEkyo@nathan>
<Z0c9XVU6aTd8neRr@nathan>
<1865227.1732723416@sss.pgh.pa.us>
<CA+hUKGKKNAc599Vp7kFAnLE1=V=ceYujz_YQoSNrvNFGaJ6i7w@mail.gmail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, thomas.munro@gmail.com, nathandbossart@gmail.com, bertranddrouvot.pg@gmail.com, bruce@momjian.us, adam@labkey.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
In-Reply-To: <2094158.1732812306@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
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