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

From Chris Travers
Subject Re: Proposal for Signal Detection Refactoring
Date
Msg-id CAN-RpxAMvimQdbz1g5D4QKfp8Cn-hB0WV2kqW9qDY9dVgqqErQ@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for Signal Detection Refactoring  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Proposal for Signal Detection Refactoring
List pgsql-hackers


On Fri, Sep 21, 2018 at 6:46 AM Michael Paquier <michael@paquier.xyz> wrote:
On Thu, Sep 20, 2018 at 03:08:34PM +0200, Chris Travers wrote:
> So here's a small patch.  I will add it for the next commit fest unless
> anyone has any reason I shouldn't.

-       return InterruptPending && (QueryCancelPending || ProcDiePending);
+       return PENDING_INTERRUPT_LEVEL() >= QUERY_CANCEL;

This is pretty similar to lock levels, where it is pretty hard to put a
strict monotone hierarchy when it comes to such interruptions. 

I understand how lock levels don't fit a simple hierarchy but at least when it comes
to what is going to be aborted on a signal, I am having trouble understanding the problem here.

Does anyone have any search terms I should look into the archives regarding this issue?

I will assume this patch will be rejected then.

 
The new
code does not seem like an improvment either, as for example in the code
mentioned above, you know directly what are the actions involved, which
is not the case with the new code style.

The initial motivation for this patch was that it felt a little bit odd to be using global 
boolean flags for this sort of approach and I was concerned that if this approach
proliferated it might cause problems later.  As far as I know my previous patch was
the second use of the current pattern.

So one thing I wonder is if there are ways where abstracting this would make more sense.
 
--
Michael


--
Best Regards,
Chris Travers
Head of Database

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

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: transction_timestamp() inside of procedures
Next
From: Chris Travers
Date:
Subject: Re: proposal: prefix function