Re: Interrupts vs signals - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Interrupts vs signals
Date
Msg-id d446c315-5af9-4537-9cd9-605fd1b58412@iki.fi
Whole thread Raw
In response to Re: Interrupts vs signals  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Interrupts vs signals
Re: Interrupts vs signals
List pgsql-hackers
On 18/02/2026 02:11, Heikki Linnakangas wrote:
> On 14/02/2026 23:56, Andres Freund wrote:
>> Could we have the mask of interrupts that WaitInterrupt() is waiting 
>> for in a
>> second variable? That way we could avoid interrupting WaitInterrupt() 
>> when
>> raising or sending a signal that WaitInterrupt() is not waiting for.  
>> I think
>> that can be one race-freely with a bit of care?
> 
> Yeah, I thought of that, but I'm not sure what the right tradeoff here 
> is. I doubt the spurious wakeups matter much in practice. Then again, 
> maybe it's not much more complicated, so maybe I should try that.
> 
> Now with this new version, the same consideration applies to the 
> CFI_ATTENTION flag I added. We could expose a process's 
> CheckForInterruptsMask alongside the pending interrupts, so it would be 
> SendInterrupt()'s responsibility to check if the receiving backend's 
> CheckForInterruptsMask includes the interrupt that's being sent. That 
> would similarly eliminate the "false positive" ProcessInterrupts() calls 
> from CHECK_FOR_INTERRUPTS(), by moving the logic to the senders. The 
> SLEEPING_ON_INTERRUPTS and CFI_ATTENTION flags are quite symmetrical.

I tried that approach, exposing an "attention bitmask" where a backend 
advertises which interrupts it's currently interested in. I think I like it.

Patch attached. The relevant changes for this "attention mechanism" are 
in the last patch, but there are some other small changes too so this 
split into patches is a little messy. I moved the list of standard 
interrupts to a separate header file, for example. So for reviewing, I 
recommend reading the resulting interrupt.h and interrupt.c files after 
applying all the patches, instead of trying to read the diff for those.

- Heikki

Attachment

pgsql-hackers by date:

Previous
From: David Geier
Date:
Subject: Re: Reduce planning time for large NOT IN lists containing NULL
Next
From: Tom Lane
Date:
Subject: Re: ecdh support causes unnecessary roundtrips