From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
cc: Jakub Wartak <jakub.wartak@enterprisedb.com>,
        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>
Subject: Re: Add errdetail() with PID and UID about source of termination
 signal
In-reply-to: <c7ec08db-e5e0-42bf-acaa-4cc09d9649f6@dunslane.net>
References: <CFD6C011-7D95-418B-B7BA-5F864F682C83@gmail.com>
 <a076e20d-fc56-4b5d-aa47-a52b4e7a5061@dunslane.net>
 <j7gm4f7bx7hprsc6j4tl47nd5r2vfv5aqevco76rsdawvkwfnd@nsbig7xqlqj5>
 <9179378a-42db-4315-9ff6-b849ad5eefaf@dunslane.net>
 <6cj4oxgdpavltoqdbydw2pgxfdbcejc26x3mitasrnswipxne5@7gkaeoibos4l>
 <71930E58-82A8-4DDC-BA8C-5E394331E463@gmail.com>
 <43ab327c-3ec7-4424-88de-22c7906e5529@uni-muenster.de>
 <jygesyr7mwg7ovdbxpmjvvbi3hccptpkcreqb645h7f56puwbz@hmkkwi3melfe>
 <acd7c8a3-9646-4023-8938-d49eb9c6a3f1@dunslane.net>
 <8B3A69A4-8412-472D-BB39-47617E430420@gmail.com>
 <CAKZiRmws3_4xemjzP9kyp=co=gc1GXoZ2VtqZzGuO9-tN8ok8Q@mail.gmail.com>
 <833f045b-286a-45dc-aad1-28854cbacc99@dunslane.net>
 <CAKZiRmwV-46KOYQM5OP4FZWJFqsELAVCTE++_XBHoX8hAFdpAg@mail.gmail.com>
 <d73b6ec7-f053-4175-8b6f-281fcb828899@dunsla! ne.net>
 <1997398.1776263852@sss.pgh.pa.us> <30efa6ac-4b7f-43c3-aab6!
 -c0a3c74daac6@dunslane.net> <2007157.1776269052@sss.pgh.pa.us>
 <c7ec08db-e5e0-42bf-acaa-4cc09d9649f6@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Wed, 15 Apr 2026 13:20:03 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2100110.1776278946.1@sss.pgh.pa.us>
Date: Wed, 15 Apr 2026 14:49:06 -0400
Message-ID: <2100111.1776278946@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2100111.1776278946%40sss.pgh.pa.us>
Precedence: bulk

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

			regards, tom lane