pg.ddx.io  pgsql-bugs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bruce Momjian <bruce@momjian.us>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.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, 21 Nov 2024 13:05:38 -0500
Message-ID: <Zz92cka2VlBDsat3@momjian.us> (raw)
In-Reply-To: <Zz9pOi3pGF-DnJTp@nathan>
References: <158506.1732120196@sss.pgh.pa.us>
	<Zz4TcYSNWW1_Vj--@nathan>
	<Zz5kfP7fIuoY8I45@nathan>
	<Zz7g2s0GSBelWmpg@ip-10-97-1-34.eu-west-3.compute.internal>
	<Zz9B3KQGXFCGVPXy@momjian.us>
	<Zz9FRrwJRlyGBFPN@ip-10-97-1-34.eu-west-3.compute.internal>
	<Zz9IHPBf-z8MsLdw@momjian.us>
	<Zz9OTyWAvATeeHev@nathan>
	<Zz9jfOkVmlYcYHSy@momjian.us>
	<Zz9pOi3pGF-DnJTp@nathan>

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?"





view thread (67+ messages)  latest in thread

Message-ID: <Zz92cka2VlBDsat3@momjian.us>
Permalink:  ../Zz92cka2VlBDsat3@momjian.us/
Also on:    postgresql.org/message-id/Zz92cka2VlBDsat3@momjian.us

 · 

reply

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: bruce@momjian.us, nathandbossart@gmail.com, bertranddrouvot.pg@gmail.com, tgl@sss.pgh.pa.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: <Zz92cka2VlBDsat3@momjian.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