Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tEBYn-005li9-2k for pgsql-bugs@arkaria.postgresql.org; Thu, 21 Nov 2024 18:05:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tEBYl-0008GV-ID for pgsql-bugs@arkaria.postgresql.org; Thu, 21 Nov 2024 18:05:43 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tEBYl-0008GN-9b for pgsql-bugs@lists.postgresql.org; Thu, 21 Nov 2024 18:05:43 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tEBYi-003946-Rz for pgsql-bugs@lists.postgresql.org; Thu, 21 Nov 2024 18:05:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=bfiHVPBEvTqcp4oEex89gGJRTNgaNmZ+fP8ApA9J0SE=; b=TcBAR itbWbeKz3SiCUJlaiWTAe9ArUv+DHwJI/kZBRFh1C7vHqyfx9PwfwGf9Yzld+PFoidzoyPb8bGnEQ eufwvsCewTFZ3LRD8xh67rQgI5AwMNOF35Y6T70RFvGf29cLMRRo+BiW+7IB60cegolgCrBXeTHAL jony3oemEqVwgpmqXV3GPJo5ACCNGb4vYM3oQd6jODfMPAEAJEHJxXc6Uc1LxqQaF22Ue7AB1s1IK VPkecQBWFDS2IhwNNVwZ9kIT/Afo6GIHD/olAgk/7ZUbKVF2VM0/jMw2D7HxivUbRwxUqn2rPoo38 bjPZL2rkgdvFGtqfmcOgXw9qNhi1Q==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1tEBYg-000O9L-1q; Thu, 21 Nov 2024 13:05:38 -0500 Date: Thu, 21 Nov 2024 13:05:38 -0500 From: Bruce Momjian To: Nathan Bossart Cc: Bertrand Drouvot , Tom Lane , 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 Message-ID: References: <158506.1732120196@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 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?"