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

Hi,

On 2026-04-09 06:59:39 -0400, Andrew Dunstan 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.

Yea, I think it'd be worse. It's also what I had tried first.

> 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.

I think Chao's point about needing to initialize uid to a better unset value
also needs to be fixed, at least.

Greetings,

Andres Freund