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.96) (envelope-from ) id 1wtsiG-000KND-0O for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Aug 2026 20:04:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wtsiD-003yxC-33 for pgsql-hackers@arkaria.postgresql.org; Tue, 11 Aug 2026 20:04:39 +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.96) (envelope-from ) id 1wtsiD-003yx3-26 for pgsql-hackers@lists.postgresql.org; Tue, 11 Aug 2026 20:04:38 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wtsiD-00000000A9C-0CJh for pgsql-hackers@lists.postgresql.org; Tue, 11 Aug 2026 20:04:37 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.18.1/8.18.1) with ESMTP id 67BK4FTR2537863; Tue, 11 Aug 2026 16:04:15 -0400 From: Tom Lane To: Andres Freund cc: Heikki Linnakangas , =?utf-8?Q?=C3=81lvaro?= Herrera , "Masashi Kamura (Fujitsu)" , "'pgsql-hackers@lists.postgresql.org'" , Jeff Davis Subject: Re: Crash issue in PG18.5 regression In-reply-to: References: Comments: In-reply-to Andres Freund message dated "Tue, 11 Aug 2026 14:31:22 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2537861.1786478655.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Aug 2026 16:04:15 -0400 Message-ID: <2537862.1786478655@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > It also seems like we really ought to have an actually reachable, curren= tly > crashing, to_date() call in the tests? It seems concerning that > seq_search_localized(), casefold_str_cmp() are completely uncovered toda= y, and > quite obviously we can't be relied upon to get this right. All that code is reached when I run the core regression tests under LANG=3DC.utf8 or LANG=3Den_US.utf8, except for the "As last resort" stanza at the bottom of seq_search_localized()'s loop. I suppose the coverage.postgresql.org animal is either not Linux or doesn't test any UTF8 encoding, but that's not the fault of our test cases, and it doesn't reflect what I think actually happens in the buildfarm. Yeah, it'd be good if we could devise a test case that reaches the "As last resort" bit, but that's irrelevant to the current problem. The reason we failed to notice this sooner is that the crash is only reached with (a) locale =3D "C" and (b) either a multi-byte encoding, so that we reach strupper_libc_mb, or a single-byte encoding with some high-bit-set characters, so that strupper_libc_sb invokes libc. The regression test cases that might have noticed this are in collate.linux.utf8.sql, so we need locale =3D "C" + encoding =3D UTF8 + a Linux test machine that has a reasonable set of locales installed. That would have been enough to find it, except that the buildfarm client doesn't have any easy way to test locale =3D "C" with encoding =3D UTF8. It will test locale =3D "C" with encoding SQL_ASCII, which doesn't run collate.linux.utf8.sql, and it will test other cases as set up by the machine owner, but there's no way to tell it to use that specific locale+encoding combination. I've tried "LANG=3DC.utf8", but that doesn't reach the crash, probably because it doesn't cause us to take the locale_is_c optimization paths. (Should it? I'm unsure.) So I'm not seeing a huge failure to test here. We missed a very narrow combination of cases. regards, tom lane