Horton

Re: Potential ABI breakage in upcoming minor releases

Tom Lane <tgl@sss.pgh.pa.us>

View thread
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>
Date: 2024-11-15T20:29:21Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Undo unintentional ABI break in struct ResultRelInfo.

  2. For inplace update durability, make heap_update() callers wait.

  3. Fix btmarkpos/btrestrpos array key wraparound bug.

  4. Fix calculation of which GENERATED columns need to be updated.

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 future
> 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