Re: Add errdetail() with PID and UID about source of termination signal
Jim Jones <jim.jones@uni-muenster.de>
From: Jim Jones <jim.jones@uni-muenster.de>
To: Chao Li <li.evan.chao@gmail.com>, Andres Freund <andres@anarazel.de>
Cc: Andrew Dunstan <andrew@dunslane.net>,
Jakub Wartak <jakub.wartak@enterprisedb.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-08T09:13:40Z
Lists: pgsql-hackers
Hi On 08/04/2026 03:03, Chao Li wrote: > 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. I have a few questions (slightly unrelated to Chao's fix) I'm a bit confused with the data flow and the data types involved: 1) in pgsignal.c it's volatile sig_atomic_t #if !defined(FRONTEND) && defined(HAVE_SA_SIGINFO) static volatile sig_atomic_t pqsignal_has_sender[PG_NSIG]; static volatile sig_atomic_t pqsignal_sender_pid[PG_NSIG]; static volatile sig_atomic_t pqsignal_sender_uid[PG_NSIG]; #endif 2) in postgres.c it's int int sender_pid; int sender_uid; 3) and in globals.c it is volatile int volatile int ProcDieSenderPid = 0; volatile int ProcDieSenderUid = 0; I guess 2) is ok, since it seems to be a one time read, but I'm wondering if the consumer in 3) should also use volatile sig_atomic_t: in globals.c volatile sig_atomic_t ProcDieSenderPid = 0; volatile sig_atomic_t ProcDieSenderUid = 0; in miscadmin.h extern PGDLLIMPORT volatile sig_atomic_t ProcDieSenderPid; extern PGDLLIMPORT volatile sig_atomic_t ProcDieSenderUid; If I understood this thread correctly, the feature (v6) introduced a problematic dual signature for wrapper_handler in pgsignal.c: +#if !defined(FRONTEND) && defined(HAVE_SA_SIGINFO) +static void +wrapper_handler(int signo, siginfo_t * info, void *context) +#else static void wrapper_handler(SIGNAL_ARGS) +#endif .. and it should be rather done in the source (c.h) where SIGNAL_ARGS is defined: #ifndef SIGNAL_ARGS #define SIGNAL_ARGS int postgres_signal_arg #endif Something like: #ifndef SIGNAL_ARGS #ifdef HAVE_SA_SIGINFO #define SIGNAL_ARGS int postgres_signal_arg, siginfo_t *postgres_signal_info, void *postgres_signal_context #else #define SIGNAL_ARGS int postgres_signal_arg #endif #endif But wouldn't it mean that all handlers need to be updated as well, since they'd get new parameters? If this is the case, the change can be quite substantial. Best, Jim
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