Re: Interrupts vs signals

On Wed, Oct 30, 2024 at 12:03 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> 1. Any extensions using WaitLatch, SetLatch, ResetLatch need to be
> changed to use WaitInterrupt, SetInterrupt/RaiseInterrupt,
> ResetInterrupt instead.
>
> 2. If an extension is defining its own Latch with InitLatch, rather than
> using MyLatch, it's out of luck. You could probably rewrite it using the
> INTERRUPT_GENERAL_WAKEUP, which is multiplexed like MyLatch, but it's a
> bit more effort.
>
> We can provide backwards compatibility macros and a new facility to
> allocate custom interrupt bits. But how big of a problem is this anyway?
> In an in-person chat last week, Andres said something like "this will
> break every extension".

Seems hyperbolic.

> For comparison, in PostgreSQL v10, we added a new 'wait_event_info'
> argument to WaitLatch and WaitLatchForSocket. That breakage was on
> similar scale:
>
> $ ls -d */* | xargs -IFOO bash -c "grep -q -r -I WaitLatch FOO &&
> echo FOO" | wc -l
> 71

However, that was also pretty easy to fix. This seems like it might be
a little more complicated.

> We have a few options for how to deal with backwards-compatibility for
> extensions:
>
> A) If we rip off the bandaid in one go and don't provide any
> backwards-compatibility macros, we will break 96 extensions. Most of
> them can be fixed by replacing WaitLatch, SetLatch, ResetLatch with
> corresponding WaitInterrupt, RaiseInterrupt, ResetInterrupt calls. (With
> #ifdef for compatibility with older postgres versions)
>
> B) If we provide backwards-compatibility macros so that simple Latch
> calls on MyLatch continue working, we will break about 14 extensions.
> They will need some tweaking like in option A). A bit more than the
> simple cases in option A), but nothing too difficult.
>
> C) We could provide "forward-compatibility" macros in a separate header
> file, to make the new "SetInterrupt" etc calls work in old PostgreSQL
> versions. Many of the extensions already have a header file like this,
> see e.g. citusdata/citus/src/include/pg_version_compat.h,
> pipelinedb/pipelinedb/include/compat.h. It might actually be a good idea
> to provide a semi-official header file like this on the Postgres wiki,
> to help extension authors. It would encourage extensions to use the
> latest idioms, while still being able to compile for older versions.
>
> I'm leaning towards option C). Let's rip off the band-aid, but provide
> documentation for how to adapt your extension code. And provide a
> forwards-compatibility header on the wiki, that extension authors can
> use to make the new Interrupt calls work against old server versions.

I don't know which of these options is best, but I don't find any of
them categorically unacceptable.

--
Robert Haas
EDB: http://www.enterprisedb.com