Re: Add errdetail() with PID and UID about source of termination signal
| От | Chao Li |
|---|---|
| Тема | Re: Add errdetail() with PID and UID about source of termination signal |
| Дата | |
| Msg-id | 71930E58-82A8-4DDC-BA8C-5E394331E463@gmail.com обсуждение |
| Ответ на | Re: Add errdetail() with PID and UID about source of termination signal (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Add errdetail() with PID and UID about source of termination signal
|
| Список | pgsql-hackers |
> 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 andexposed 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/
Вложения
В списке pgsql-hackers по дате отправления: