Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 31 Oct 2024 09:32:16 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
	Thomas Munro <thomas.munro@gmail.com>,
	Fujii Masao <masao.fujii@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
	Andres Freund <andres@anarazel.de>
Subject: Re: Interrupts vs signals
Message-ID: <ZyLQEG1KfCts3N_3@paquier.xyz>
References: <CA+hUKGJACzP++3PifHTMgG2xgTD4irap6+CXBMogKKiD43VqoA@mail.gmail.com>
 <CA+hUKGLAZCxzyhyoYz0BmGkqkmj-38ZfToF1GqNYhU+Br+XCLQ@mail.gmail.com>
 <3b996d73-2a10-4072-a58d-0386af0cbb78@iki.fi>
 <CA+hUKGJvt8wg_KfjFLvr27LT6sYK_szngkchig6Dg_CnNGPskw@mail.gmail.com>
 <46f047a1-bfd5-406a-a0f3-97205d9529ad@iki.fi>
 <476672e7-62f1-4cab-a822-f3a8e949dd3f@iki.fi>
 <CA+hUKG+6rn1FNxvO7Wuz_aAQ4MnGW5G6+UW4nBnzwnGnuBVWyw@mail.gmail.com>
 <391abe21-413e-4d91-a650-b663af49500c@iki.fi>
 <b3930251-78d5-4379-b213-b37b469f6dfb@iki.fi>
 <CA+TgmoZQK2HfGqz3py1TaiQ3-NiVwYK4+ZTWGnm6z41mHeAksA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="vIRi769hc2omAzHJ"
Content-Disposition: inline
In-Reply-To: <CA+TgmoZQK2HfGqz3py1TaiQ3-NiVwYK4+ZTWGnm6z41mHeAksA@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/ZyLQEG1KfCts3N_3%40paquier.xyz>
Precedence: bulk


--vIRi769hc2omAzHJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 30, 2024 at 01:23:54PM -0400, Robert Haas wrote:
> On Wed, Oct 30, 2024 at 12:03=E2=80=AFPM Heikki Linnakangas <hlinnaka@iki=
=2Efi> 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".
>=20
> 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.
>=20
> 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

--vIRi769hc2omAzHJ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmci0BAACgkQnvQgOdby
QH3pQg/+PWyiTe5KwwB8bcc15DPOQhr0/ZwQT507N2sjBmxgpzwKWgBpMA3xbKIN
sO8Xa85Hr5oosgze++gDqlfxs0miFSeRJQmWQHHO/YMybQZ/MA5TSvnetGQaOafe
tHuxZtvoFFYPw3y9LqXu9gNHbr8xV9g8VTaiEjxM1zVxNRcGP940ebYMwoxkhjcH
S8n1Z0bEMZrq5Q83WUYSTxyhLWJi3Po6qOB89TKjuvEVI+OU8vABSos35HO9vsxM
7xAkoKc4plcxoQYBQ7kPa4Dm59ralMAxXWDPZVtT3+AOVEpcMX2vstDIBwSTHef6
Wg3qjId8y9Dj2u2hiBnhJ1nD0d0kh90R8DfPpBPY2DjTndHb7q3H2g5b6PTpiO+A
YQJONjFLsA+5HKtgt93YZtdUlinUYBNCc5ELxfnp9gOjKc0Qn+8zHYCaFRN6pzRV
RvzBxrKu3i4iBYdHPFVsHMsILe3mc1kyzXFLH8JzHoiTUOnE6HidfVTeTR2ESV6T
abAEEBRS23DeUwhno7mrN7MMaeW05FeMHIfNKcHef56JTthepxVh0Wn4OhnQeIsE
p/tnhoj+qIwAsPQmIhdR6jtQrC/G/fNcTcDalaUR6Z3sZQMXiOyY+FSIOsQ0ZuYu
aUv2SLg0T0CRy/PSqnAzGL6zjfv6urhnLxIOH5S3cqTsIzCdNck=
=ZyGu
-----END PGP SIGNATURE-----

--vIRi769hc2omAzHJ--