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 -J.
