Re: Proposal for Signal Detection Refactoring - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Proposal for Signal Detection Refactoring
Date
Msg-id 20180924235725.GA1354@paquier.xyz
Whole thread Raw
In response to Re: Proposal for Signal Detection Refactoring  (Andres Freund <andres@anarazel.de>)
Responses Re: Proposal for Signal Detection Refactoring
Re: Proposal for Signal Detection Refactoring
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: "Bradley DeJong"
Date:
Subject: Re[2]: Adding a note to protocol.sgml regarding CopyData
Next
From: Andres Freund
Date:
Subject: Re: Proposal for Signal Detection Refactoring