From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Chris Travers <chris(dot)travers(at)adjust(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Proposal for Signal Detection Refactoring |
Date: | 2018-09-25 01:02:09 |
Message-ID: | 20180925010209.GC1354@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 24, 2018 at 05:23:56PM -0700, Andres Freund wrote:
> On 2018-09-25 08:57:25 +0900, Michael Paquier wrote:
>> 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...
Sure, I forgot to write the "foo = 1 << 0" and such ;)
>> 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.
I see. I thought that it mapped at least int, but C99 tells that it
can be as small as char. That's indeed quite limited...
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-09-25 01:03:49 | Re: Proposal for Signal Detection Refactoring |
Previous Message | Michael Paquier | 2018-09-25 00:58:07 | Re: Revoke execution permission of pg_stat_statements_reset() from pg_read_all_stats role |