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 →
  1. Only show signal-sender PID/UID detail in server log

  2. Make psql DETAIL line test unconditionally optional.

  3. Rework signal handler infrastructure to pass sender info as argument.

  4. Add errdetail() with PID and UID about source of termination signal.