Re: Proposal for Signal Detection Refactoring

On Mon, Sep 24, 2018 at 10:06:40AM -0700, Andres Freund wrote:
> This doesn't seem to solve an actual problem, why are we discussing
> changing this? What'd be measurably improved, worth the cost of making
> backpatching more painful?

My point was just to reduce the number of variables used and ease
debugger lookups with what is on the stack.

Anyway, putting the back-patching pain aside, and just for my own
knowledge...  Andres, would it be fine to just use one sig_atomic_t
field which can be set from different code paths?  Say:
typedef enum SignalPendingType {
    PENDING_INTERRUPT,
    PENDING_CANCEL_QUERY,
    PENDING_PROC_DIE,
    PENDING_RELOAD,
    PENDING_SESSION_TIMEOUT
};
extern volatile sig_atomic_t signalPendingFlags;

And then within separate signal handlers things like:
void
StatementCancelHandler(SIGNAL_ARGS)
{
    [...]
    signalPendingFlags |= PENDING_INTERRUPT | PENDING_CANCEL_QUERY;
    [...]
}

void
PostgresSigHupHandler(SIGNAL_ARGS)
{
    [...]
    signalPendingFlags |= ConfigReloadPending;
    [...]
}
--
Michael