> 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/
