Re: Interrupts vs signals - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Interrupts vs signals
Date
Msg-id CA+hUKGK7122M5Zzq6n9QfbgO7wUwosnZLGJdPfDcUcUFBPhamg@mail.gmail.com
Whole thread Raw
In response to Re: Interrupts vs signals  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Wed, Jan 29, 2025 at 10:15 AM Andres Freund <andres@anarazel.de> wrote:
> I was chatting with Heikki about this patch and he mentioned that he recalls a
> patch that did some work to unify the signal replacement, procsignal.h and
> CHECK_FOR_INTERRUPTS(). Thomas, that was probably from you? Do you have a
> pointer, if so?

Yeah, attempts at that were included in earlier versions in this very
thread, but then Heikki came up with the
let's-just-replace-latches-completely concept and rejiggered the lower
level patches around that (which I liked and support).  I will try to
rebase/reorganise the accompanying procsignal removal part on top of
this version today, more soon...  (I had meant to do that earlier but
got a bit distracted by summer holiday season down here and some
personal stuff, sorry for the delay on that).

> It does seem like we're going to have to do some unification here. We have too
> many different partially overlapping, partially collaborating systems here.

Right, my goal from the start of this thread was always a full
unification leaving just one single system for this type of IPC, and
Heikki's latest version is a transitional point; hopefully with the
other stuff rebased on top we'll be getting pretty close to that, at
least for the procsignal part.  More soon.



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Eagerly scan all-visible pages to amortize aggressive vacuum
Next
From: Peter Smith
Date:
Subject: Re: Proposal: Filter irrelevant change before reassemble transactions during logical decoding