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 1tEuHb-00AMyt-Vh for pgsql-bugs@arkaria.postgresql.org; Sat, 23 Nov 2024 17:51:00 +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 1tEuHa-002YMD-LS for pgsql-bugs@arkaria.postgresql.org; Sat, 23 Nov 2024 17:50:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tEuHa-002YHf-30 for pgsql-bugs@lists.postgresql.org; Sat, 23 Nov 2024 17:50:58 +0000 Received: from momjian.us ([72.94.173.45]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tEuHX-003PLO-GW for pgsql-bugs@lists.postgresql.org; Sat, 23 Nov 2024 17:50:56 +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=8lHCI2Dx81pe34fNkaWPrkoGbAuPOJbttBeORV+B7ew=; b=UDZsZ arDn05JLAg33cfsozhdvJCtas9pv20J22gJ4s+hMpYkXarW+EiGGFOL1MzhfBoaDA+g1oqNav7zmZ GXbQ9euel2VyzSOrtXS7YFR+/TVhrW+vSZmXUIBsN+3lze85pj69R4e6TIO3+XndyXuFjdj02qfmj Vvq8HbW2sEc6IoDXxqJfhIKqtzuVRup7mlgLZZO3ypNaw7F1sOBJxdV4dXLk+xjoR6W0PBCuFMrUa OR2BADC9pDQ7QofkISdbSRNdgbziKCeihhEOEVE+Fc7Y9WcEaIqVlA8oncUIpHR97WhUBrGvKAd6/ NSafzNaV7tGFZKwQRL0oYqDI83SqA==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1tEuHV-00D4l1-07; Sat, 23 Nov 2024 12:50:53 -0500 Date: Sat, 23 Nov 2024 12:50:53 -0500 From: Bruce Momjian To: Tom Lane Cc: Bertrand Drouvot , Nathan Bossart , 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: <659706.1732303427@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <659706.1732303427@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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 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?"