> On Apr 8, 2026, at 06:56, Andres Freund <[email protected]> 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/




Attachment: errdetail-pid-fix3.diff
Description: Binary data

Reply via email to