On Wed, Oct 30, 2024 at 01:23:54PM -0400, Robert Haas wrote: > On Wed, Oct 30, 2024 at 12:03 PM Heikki Linnakangas <hlinn...@iki.fi> wrote: >> 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.
Most extensions that rely on bgworkers, at least. > However, that was also pretty easy to fix. This seems like it might be > a little more complicated. The advantage of the breakage is also to force extension maintainers to look at the changes because these have benefits. I'd like to think that 6f3bd98ebfc0 was a good move overall even if it broke come compilations and these require more PG_VERSION_NUM magic. For the extension maintainer hat on, it is always annoying, but not really that bad in the long-term. >> 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. Looking at the compatibility macros of 0008 for the latches with INTERRUPT_GENERAL_WAKEUP under latch.h, the changes are not that bad to adapt to, IMO. It reminds of f25968c49697: hard breakage, no complaints I've heard of because I guess that most folks have been using an in-house compatibility headers. A big disadvantage of B is that someone may decide to add new code in core that depends on the past routines, and we'd better avoid that for this new layer of APIs for interrupt handling. A is a subset of C: do a hard switch in the core code, with C mentioning a compatibility layer in the wiki that does not exist in the core code. Any of A or C is OK, I would not choose B for the core backend. -- Michael
signature.asc
Description: PGP signature
