Re: Crash issue in PG18.5 regression

Andres Freund <andres(at)anarazel(dot)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