Re: Proposal for Signal Detection Refactoring

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Proposal for Signal Detection Refactoring
Дата
Msg-id 20180925002356.6xwuhf6rdzd4qrxp@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Proposal for Signal Detection Refactoring  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Proposal for Signal Detection Refactoring  (Michael Paquier <michael@paquier.xyz>)
Re: Proposal for Signal Detection Refactoring  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Proposal for Signal Detection Refactoring
Следующее
От: Andrew Gierth
Дата:
Сообщение: Re: Implementing SQL ASSERTION