From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Álvaro Herrera <alvherre@kurilemu.de>
Cc: Masashi Kamura (Fujitsu) <kamura.masashi@fujitsu.com>
Cc: 'pgsql-hackers@lists.postgresql.org' <pgsql-hackers@lists.postgresql.org>
Cc: Jeff Davis <pgsql@j-davis.com>
Subject: Re: Crash issue in PG18.5 regression
Date: Tue, 11 Aug 2026 16:04:15 -0400
Message-ID: <2537862.1786478655@sss.pgh.pa.us> (raw)
In-Reply-To: <v3nniwcrxejmcfvz56xbd22hphprqleuornd6hqkmw2bl7kgmz@cnytz2ee5ltk>
References: <anq-x9lmTO-mKL_k@alvherre.pgsql>
<a9c06b03-94ec-4871-9271-cb776a2d0378@iki.fi>
<f72a8fbe-7ef1-4cd3-8a4b-fd9106480510@iki.fi>
<v3nniwcrxejmcfvz56xbd22hphprqleuornd6hqkmw2bl7kgmz@cnytz2ee5ltk>
Andres Freund <andres@anarazel.de> writes:
> It also seems like we really ought to have an actually reachable, currently
> crashing, to_date() call in the tests? It seems concerning that
> seq_search_localized(), casefold_str_cmp() are completely uncovered today, 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=C.utf8 or LANG=en_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 = "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 = "C" + encoding = 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 = "C" with
encoding = UTF8. It will test locale = "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=C.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
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-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, hlinnaka@iki.fi, alvherre@kurilemu.de, kamura.masashi@fujitsu.com, pgsql-hackers@lists.postgresql.org, pgsql@j-davis.com
Subject: Re: Crash issue in PG18.5 regression
In-Reply-To: <2537862.1786478655@sss.pgh.pa.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