On Thu, Apr 16, 2026 at 8:09 AM Jakub Wartak <[email protected]> wrote: > > On Wed, Apr 15, 2026 at 9:39 PM Andrew Dunstan <[email protected]> wrote: > > > > > > On 2026-04-15 We 2:49 PM, Tom Lane wrote: > > > > Andrew Dunstan <[email protected]> writes: > > > > On 2026-04-15 We 12:04 PM, Tom Lane wrote: > > > > As a short-term fix, we could just go back to allowing the regex to > > consider the match optional. > > > > Ok, so we can get the buildfarm green I'll go and do that. But I think > > we should have an open item to tighten the test. > > > > I did some more digging, and got this from Google's AI Mode: > > > > ----- > > openbsd does not fill siginfo_t si_pid for SIGTERM > > > > On OpenBSD, si_pid is indeed not guaranteed to be filled for SIGTERM > > (and many other signals), even when using SA_SIGINFO. This is a known > > architectural behavior of the OpenBSD kernel rather than a bug. > > > > Why si_pid is zero or empty > > > > Minimalist Kernel Design: Unlike Linux, which often populates si_pid > > and si_uid for most user-sent signals, the OpenBSD kernel only > > guarantees these fields for specific signals where they are > > functionally required by POSIX, such as SIGCHLD. > > > > Security & Information Leakage: OpenBSD has a history of limiting > > information available across process boundaries to prevent > > side-channel attacks or unnecessary information leaks about other > > processes on the system [0.31]. > > > > Signal Queueing: Standard signals like SIGTERM are not "queued" with > > data in the same way real-time signals (which OpenBSD does not fully > > support in the same manner as Linux) would be. > > ----- > > > > Now, none of the links it provided in support of these claims say > > any such thing AFAICS, so maybe this is all an AI hallucination. > > We could probably look into the OpenBSD kernel to check it, if we > > were sufficiently motivated. But I'm inclined to believe it and > > just say "this info is not available on all platforms, even some > > that HAVE_SA_SIGINFO". > > > > > > > > > > > > Thanks for looking into this. I guess we could make a test to see what the > > platform will support, but it seems like overkill. So now I'm just inclined > > to go back to making the line completely optional in the test and leave it > > at that. > > > > +1
And here is the patch for that. -J.
From 8f5ef144acf5f15c132df655fd6f566f7d0d3233 Mon Sep 17 00:00:00 2001 From: Jakub Wartak <[email protected]> Date: Thu, 16 Apr 2026 10:00:40 +0200 Subject: [PATCH v1] Fix test about the lack of the errdetail() signal info about PID/UIDs on OpenBSD. Commit 3e2a1496bae6 made the psql TAP test require the DETAIL line on platforms with SA_SIGINFO, rather than making it optional. This unexpectly blowed up on OpenBSD buildfarm members, because OpenBSD is not setting si_pid properly for SIGTERM signals even while having SA_SIGINFO defined. Make the DETAIL line optional as it was in 55890a919454. Author: Jakub Wartak <[email protected]> Suggested-by: Tom Lane <[email protected]> Reviewed-by: Andrew Dunstan <[email protected]> Discussion: https://www.postgresql.org/message-id/2007157.1776269052%40sss.pgh.pa.us --- src/bin/psql/t/001_basic.pl | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/bin/psql/t/001_basic.pl b/src/bin/psql/t/001_basic.pl index 9d966c7bece..7c21204c1f2 100644 --- a/src/bin/psql/t/001_basic.pl +++ b/src/bin/psql/t/001_basic.pl @@ -142,11 +142,8 @@ my ($ret, $out, $err) = $node->psql('postgres', is($ret, 2, 'server crash: psql exit code'); like($out, qr/before/, 'server crash: output before crash'); unlike($out, qr/AFTER/, 'server crash: no output after crash'); -my $detail_re = check_pg_config("#define HAVE_SA_SIGINFO 1") - ? qr/DETAIL: Signal sent by PID \d+, UID \d+\.\n/ - : qr//; like( $err, qr/psql:<stdin>:2: FATAL: terminating connection due to administrator command -${detail_re}psql:<stdin>:2: server closed the connection unexpectedly +(?:DETAIL: Signal sent by PID \d+, UID \d+\.\n)?psql:<stdin>:2: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:<stdin>:2: error: connection to server was lost/, -- 2.43.0
