Re: Interrupts vs signals - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Interrupts vs signals
Date
Msg-id 818bafaf-1e77-4c78-8037-d7120878d87c@iki.fi
Whole thread Raw
In response to Re: Interrupts vs signals  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Interrupts vs signals
List pgsql-hackers
On 29/01/2026 03:05, Heikki Linnakangas wrote:
> Here's a new rebased and massively re-worked patch.
> 
> The patches are split differently than in the previous version:
> - Patches 0001-0005 are just refactoring around recovery conflicts which 
> I posted on a separate thread [1]. Please review and comment there.
> - Patches 0006 and 0007 are small cleanups that could be applied early 
> (after updating the docs, as noted in TODO comment there).
> - All the interesting bits for this thread are in the last, massive patch.
> 
> To review this, I suggest starting from the new src/backend/ipc/ 
> README.md file. It gives a good overview of the mechanism (or if it 
> doesn't, that's valuable feedback :-) ). It also contains a bunch of 
> Open Questions at the bottom; I'd love to hear opinions and ideas on those.

New version attached. Lots of little cleanups, and a few more notable 
changes:

- Switched to 64-bit interrupt masks. This gives more headroom for 
extensions to reserve their own custom interrupts

- I mostly gave up on sending interrupts from postmaster to child 
processes. So postmaster still uses kill() to tell child processes to 
exit or do other things. There's a TODO section in the README about 
that, but this is fine for now.

- Implemented a RequestAddinInterrupt() function for extensions to 
request interrupt bits. (TODO: use it in one of the example extensions, 
to show how to use it and to test that it works)

> On 15/07/2025 18:50, Andres Freund wrote:
>>> @@ -205,6 +206,8 @@ StartupProcExit(int code, Datum arg)
>>>      /* Shutdown the recovery environment */
>>>      if (standbyState != STANDBY_DISABLED)
>>>          ShutdownRecoveryTransactionEnvironment();
>>> +
>>> +    ProcGlobal->startupProc = INVALID_PROC_NUMBER;
>>>  }
>>
>>
>> What if we instead had a ProcGlobal->auxProc[auxproxtype]? We have 
>> different
>> versions of this for different types auf aux processes, which doesn't 
>> really
>> make sense.
> 
> I like that idea, but didn't try it yet.

The attached patches move a little in that direction. There's no array 
like that, but I moved the responsibility of setting those 
startupProc/walreceiverProc/checkpointerProc fields to 
InitAuxiliaryProcess(), so there's now a clear pattern to copy if other 
processes need to be advertised like that.

- Heikki
Attachment

pgsql-hackers by date:

Previous
From: Alexandre Felipe
Date:
Subject: Re: Incremental View Maintenance, take 2
Next
From: Nathan Bossart
Date:
Subject: Re: [PATCH] Support reading large objects with pg_read_all_data