Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails

From: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, adam(at)labkey(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Date: 2024-11-23 08:37:18
Message-ID: Z0GUPolIKGTr9OO4@ip-10-97-1-34.eu-west-3.compute.internal
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

Attachment Content-Type Size
v6-attempt-multibyte-aware-truncation.patch text/x-diff 4.7 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bertrand Drouvot 2024-11-23 09:50:41 Re: BUG #18711: Attempting a connection with a database name longer than 63 characters now fails
Previous Message Tom Lane 2024-11-23 05:50:46 Re: Detection of hadware feature => please do not use signal