Re: Add errdetail() with PID and UID about source of termination signal

Chao Li <li.evan.chao@gmail.com>

From: Chao Li <li.evan.chao@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Andrew Dunstan <andrew@dunslane.net>, Jakub Wartak <jakub.wartak@enterprisedb.com>, Jim Jones <jim.jones@uni-muenster.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-08T01:03:33Z
Lists: pgsql-hackers

Attachments


> On Apr 8, 2026, at 06:56, Andres Freund <andres@anarazel.de> wrote:
> 
> Hi,
> 
> On 2026-04-07 17:31:18 -0400, Andrew Dunstan wrote:
>> On 2026-04-07 Tu 2:19 PM, Andres Freund wrote:
>>> On 2026-04-07 12:49:19 -0400, Andrew Dunstan wrote:
>>>> On 2026-04-07 Tu 10:55 AM, Andres Freund wrote:
>>>>> This seems completely wrong from a layering POV.  The wrapper has no business
>>>>> whatsoever to know that how SIGTERM is interpreted and thus no business
>>>>> setting variables like ProcDieSenderPid.
>>>>> 
>>>>> Pretty sure have some sigterm handlers that shouldn't set ProcDieSenderPid.
>>>>> 
>>>>> 
>>>>> A more correct answer here would be to forward information about the sender of
>>>>> a signal to the signal handlers and let them interpret the information if
>>>>> available.
>>>>> 
>>>> OK, fair points. Does the attached meet your concerns?
>>> I think the extra data should be forwarded as arguments to the "real" (not
>>> wrapper) handler, not as globals.  You can have signal handlers interrupt each
>>> others on some platforms, which means that if you're not careful, you could
>>> end up reading the values from the wrong signal.
>> 
>> 
>> OK, maybe this, then? It saves the siginfo before calling the handler, and
>> restores it after the call, so you should always be looking at the right
>> one.
> 
> I don't think that addresses my concerns at all unfortunately.  I can give
> writing a sketch of how I think it should like a go, but it won't be today and
> probably not this week.
> 
> I suspect this patch just has missed the boat for 19, but if others think we
> can fix it up in a week or two, I'm also ok. It's a feature I wanted for a
> long time.
> 
> Greetings,
> 
> Andres Freund

I tried to understand the layering comment, and I’m proposing a fix where sender information is stored within pqsignal and exposed via a new helper function, pqsignal_get_sender(). Then the signal handler retrieves the signal sender via pqsignal_get_sender() and sets ProcDieSenderPid/ProcDieSenderUid. Please see the attached diff.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/




Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Only show signal-sender PID/UID detail in server log

  2. Make psql DETAIL line test unconditionally optional.

  3. Rework signal handler infrastructure to pass sender info as argument.

  4. Add errdetail() with PID and UID about source of termination signal.