Proposal for Signal Detection Refactoring - Mailing list pgsql-hackers

From Chris Travers
Subject Proposal for Signal Detection Refactoring
Date
Msg-id CAN-RpxD_MDp_wbP2Ob_6TyRdTc+4poufEXbQUnQNVBpAcdY+YQ@mail.gmail.com
Whole thread Raw
Responses Re: Proposal for Signal Detection Refactoring
List pgsql-hackers
After the patch we did for the race condition here, one point which was brought up which I thought was quite relevant was the fact that checking global flags feels a little ugly.

I would like to set up a patch which refactors this as follows:

1.  We create an enum of cancellation levels:
    NO_INTERRUPT
    INTERRUPT
    QUERY_CANCEL
    PROCESS_EXIT

2.  We create a macro called PENDING_INTERRUPT_LEVEL() which returns the highest pending interrupt level.

3.  We check on whether the output of this is greater or equal to the level we need to handle and work on that basis.

This allows us to handle cases where we just want to check the interrupt level for return or cleanup purposes.  It does not apply to cases where we need to change interrupt handling temporarily as we do in a couple of cases.  I think it is cleaner than checking the QueryCancelPending and ProcDiePending global flags directly.

So here's a small patch.  I will add it for the next commit fest unless anyone has any reason I shouldn't.

--
Best Regards,
Chris Travers
Head of Database

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com 
Saarbrücker Straße 37a, 10405 Berlin

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Query is over 2x slower with jit=on
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: PostgreSQL 11 {Beta 4, RC1} Release: 2018-09-20