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

From Andres Freund
Subject Re: Proposal for Signal Detection Refactoring
Date
Msg-id 20180925002356.6xwuhf6rdzd4qrxp@alap3.anarazel.de
Whole thread Raw
In response to Re: Proposal for Signal Detection Refactoring  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Proposal for Signal Detection Refactoring  (Michael Paquier <michael@paquier.xyz>)
Re: Proposal for Signal Detection Refactoring  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
On 2018-09-25 08:57:25 +0900, Michael Paquier wrote:
> 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.

I'm not sure a bitflag really gives you that - before gdb gives you the
plain value, afterwards you need to know the enum values and do bit math
to know.


> 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
> };

Well, they'd have to different bits...


> extern volatile sig_atomic_t signalPendingFlags;

Note that sig_atomic_t IIRC is only guaranteed to effectively be 8 bit
wide - so you couldn't have that many flags.


Greetings,

Andres Freund


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Proposal for Signal Detection Refactoring
Next
From: Andrew Gierth
Date:
Subject: Re: Implementing SQL ASSERTION