Re: Add errdetail() with PID and UID about source of termination signal

> On Apr 9, 2026, at 18:59, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 2026-04-08 We 1:01 PM, Andres Freund wrote:
>> Hi,
>>
>> Attached is a very rough first draft for how I think this needs to look like.
>>
>> Basically, SIGNAL_INFO always will pass both the signal number and extended
>> information along to the signal handler. The extended information is a
>> postgres specific struct. If the platform can't provide the extended
>> information, the values are instead set to some default value indicating that
>> the information is not known.
>>
>> With that die() (and also StatementCancelHandler, ...) can just set whatever
>> globals it wants, without pqsignal.c needing to know about it.
>>
>> It also allows us to extend the amount of information in the future. E.g. I'd
>> like to log the reason for a segfault (could e.g. be an OOM kill or an umapped
>> region) to stderr.
>>
>> The annoying thing about it is needing to change nearly all the existing
>> references to SIG_IGN/SIG_DFL, to avoid warnings due to mismatched types.
>
> I agree that's annoying. The only way around it I found was via some casting to/from void* that I suspect you would find a cure worse than the disease.
> I reworked your patch slightly. This version fixes the translatability issue you raised earlier, makes the TAP test from the original commit more robust, and tries to resolve your XXX issue by moving the assignment of ProcDieSenderPid/Uid inside the "if (!proc_exit_inprogress)" block.
>
> cheers
>
> andrew
>
>
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com
>
> <0001-Rework-signal-sender-errdetail-to-pass-info-via-hand.patch>

I reviewed this version. Besides the compile warning and uid 0 issues, I got a few more comments, so I try to put them all together as below.

1 - compile warnings
As talked in an earlier email, this eliminates the compile warnings for me:
```
chaol(at)ChaodeMacBook-Air postgresql % git diff
diff --git a/src/include/port.h b/src/include/port.h
index 7db476d7b01..c029878c6be 100644
--- a/src/include/port.h
+++ b/src/include/port.h
@@ -547,8 +547,8 @@ extern int pg_mkdir_p(char *path, int omode);
#define pqsignal pqsignal_be
#endif

-#define PG_SIG_DFL (pqsigfunc) SIG_DFL
-#define PG_SIG_IGN (pqsigfunc) SIG_IGN
+#define PG_SIG_DFL (pqsigfunc) (pg_funcptr_t) SIG_DFL
+#define PG_SIG_IGN (pqsigfunc) (pg_funcptr_t) SIG_IGN
typedef void (*pqsigfunc) (SIGNAL_ARGS);
extern void pqsignal(int signo, pqsigfunc func);
```

2 - uid 0 problem
```
+typedef struct pg_signal_info
+{
+ pid_t pid; /* pid of sending process or 0 if unknown */
+ uid_t uid; /* uid of sending process or 0 if unknown */
+} pg_signal_info;
```

I think we can mention that “uid” is only meaningful when pid is set.

3 Also for the struct pg_signal_info. As the struct name is generic in order to hold some more fields in the future, does it make sense to rename “pid” to “sender_pid” and “uid” to “sender_pid” to reflect their actual meanings? I am thinking that, some other pid/uid might be added to this struct in the future.

4
```
-#ifndef SIGNAL_ARGS
-#define SIGNAL_ARGS int postgres_signal_arg
-#endif
+/*
+ * The following is used as the arg list for signal handlers. These days we
+ * use the same argument to all signal handlers and hide the difference
+ * between platforms in wrapper functions.
+ *
+ * SIGNAL_ARGS just exists separately from the pqsignal() definition for
+ * historical reasons.
+ */
+#define SIGNAL_ARGS int postgres_signal_arg, pg_signal_info *pg_siginfo
```

Given we now define new PG_SIG_IGN and PG_SIG_DFL, does it make sense to rename SIGNAL_ARGS to PG_SIGNAL_ARGS?

5
```
+ pg_info.uid = 0;
```

If you take comment 2, then when unavailable, we can just don’t assign anything to pg_info.uid. Or "(uid_t)-1", maybe.

6
```
+#define SIGNAL_ARGS int postgres_signal_arg, pg_signal_info *pg_siginfo
```

Maybe pg_siginfo can be const.

7
```
+ errdetail("The transaction has already committed locally, but might not have been replicated to the standby. Signal sent by PID %d, UID %d.”,
```

Per https://www.postgresql.org/docs/current/error-style-guide.html, for hint and detail messages, “Put two spaces after the period if another sentence follows”.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/