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
- errdetail-pid-fix3.diff (application/octet-stream) patch
> 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 →
-
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