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
