| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Add errdetail() with PID and UID about source of termination signal |
| Date: | 2026-04-07 21:31:18 |
| Message-ID: | 9179378a-42db-4315-9ff6-b849ad5eefaf@dunslane.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-04-07 Tu 2:19 PM, Andres Freund wrote:
> Hi,
>
> 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.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
| Attachment | Content-Type | Size |
|---|---|---|
| errdetail-pid-fix2.patch | text/x-patch | 6.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2026-04-07 21:38:11 | Re: Adding REPACK [concurrently] |
| Previous Message | Tomas Vondra | 2026-04-07 21:28:32 | Re: EXPLAIN: showing ReadStream / prefetch stats |