From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
cc: Aleksander Alekseev <aleksander@timescale.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>,
        Marco Slot <marco.slot@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Christoph Berg <myon@debian.org>,
        Pavan Deolasee <pavan.deolasee@gmail.com>
Subject: Re: Potential ABI breakage in upcoming minor releases
In-reply-to: <20241115175223.68.nmisch@google.com>
References: <1976928.1731614974@sss.pgh.pa.us> <202411142033.u6za5a6ylj2k@alvherre.pgsql> <20241114224108.d0.nmisch@google.com> <CAJ7c6TPcUJq_Bwo69f6ysRA1UbmSh_hOOEzJ2EvM0cW=3VEh5w@mail.gmail.com> <CAFMSG9Hy-2-8tfmmKy7noCbA3Yn1UY2SFUwYj7wHODTO8gDm8w@mail.gmail.com> <CAJ7c6TMCc85YoiSKex5Sztz6bEmV-0YqL7FY=_MxxcyoMGTDfQ@mail.gmail.com> <2443809.1731683394@sss.pgh.pa.us> <20241115175223.68.nmisch@google.com>
Comments: In-reply-to Noah Misch <noah@leadboat.com>
	message dated "Fri, 15 Nov 2024 09:52:23 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2483969.1731702561.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 15 Nov 2024 15:29:21 -0500
Message-ID: <2483970.1731702561@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2483970.1731702561%40sss.pgh.pa.us>
Precedence: bulk

Noah Misch <noah@leadboat.com> writes:
> On Fri, Nov 15, 2024 at 10:09:54AM -0500, Tom Lane wrote:
>> I'm starting to lean to the opinion that we need a re-wrap.

> Perhaps.  Even if we do rewrap for some reason, it's not a given that
> restoring the old struct size is net beneficial.  If we restore the old =
struct
> size in v16.6, those who rebuild for v16.5 would need to rebuild again.

I think what we should say is "sorry, 16.5 is broken for use with
these extensions, use another minor version".  If we don't undo the
struct size change then 16.5 is effectively a major version update for
affected extensions: they cannot build a binary release that works
with both older and newer minor releases.  That's a packaging
disaster, especially if it impacts more than timescale.  The more
so if more than one release branch is affected.

> Either way, users of timescaledb should rebuild timescaledb for every fu=
ture
> PostgreSQL minor release.

We really don't want that either.  I recall that somebody (Peter E?)
had been looking into tools for automatically checking ABI
compatibility in stable branches.  My takeaway from this mess is
that we need to move the priority of that project way up.

			regards, tom lane