Re: Add errdetail() with PID and UID about source of termination signal
Jakub Wartak <jakub.wartak@enterprisedb.com>
From: Jakub Wartak <jakub.wartak@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Chao Li <li.evan.chao@gmail.com>, Andres Freund <andres@anarazel.de>, Jim Jones <jim.jones@uni-muenster.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-16T06:08:06Z
Lists: pgsql-hackers
On Wed, Apr 15, 2026 at 8:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Andrew Dunstan <andrew@dunslane.net> 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". Hi Tom, It seems to be not a hallucination: it appears that they do initsiginfo() [1] which zeros out struct siginfo_t without setting si_pid there. The only reference about si_pid is that their waitid(2) fills it properly and that's visibile in their dowait*() kernel-side implementation too. -J. [1] - https://github.com/openbsd/src/blob/master/sys/kern/kern_sig.c#L2166
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Only show signal-sender PID/UID detail in server log
- b772f3fcad18 19 (unreleased) landed
-
Make psql DETAIL line test unconditionally optional.
- 446c400fd89b 19 (unreleased) landed
-
Rework signal handler infrastructure to pass sender info as argument.
- 3e2a1496bae6 19 (unreleased) landed
-
Add errdetail() with PID and UID about source of termination signal.
- 55890a919454 19 (unreleased) landed