Re: Add errdetail() with PID and UID about source of termination signal - Mailing list pgsql-hackers

From Jim Jones
Subject Re: Add errdetail() with PID and UID about source of termination signal
Date
Msg-id 43ab327c-3ec7-4424-88de-22c7906e5529@uni-muenster.de
Whole thread Raw
In response to Re: Add errdetail() with PID and UID about source of termination signal  (Chao Li <li.evan.chao@gmail.com>)
List 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
pqsignaland exposed via a new helper function, pqsignal_get_sender(). Then the signal handler retrieves the signal
sendervia 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




pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Use proc_exit() in WalRcvWaitForStartPosition
Next
From: Soumya S Murali
Date:
Subject: Re: Fix bug with accessing to temporary tables of other sessions