Horton

Re: Potential ABI breakage in upcoming minor releases

Alvaro Herrera <alvherre@alvh.no-ip.org>

View thread
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Noah Misch <noah@leadboat.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Christoph Berg <myon@debian.org>, Pavan Deolasee <pavan.deolasee@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-11-15T11:31:05Z
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.

On 2024-Nov-14, Noah Misch wrote:

> I'm hearing the only confirmed impact on non-assert builds is the need to
> recompile timescaledb.  (It's unknown whether recompiling will suffice for
> timescaledb.  For assert builds, six PGXN extensions need recompilation.)  I
> don't see us issuing another set of back branch releases for the purpose of
> making a v16.4-built timescaledb avoid a rebuild.  The target audience would
> be someone who can get a new PostgreSQL build but can't get a new timescaledb
> build.  That feels like a small audience.  What's missing in that analysis?

I agree with your conclusion that no rewrap is needed.  I previously
said otherwise, based on claims that there were multiple extensions
causing crashes.  If the one crash we know about is because timescaledb
is using an unusual coding pattern, they can fix that more easily than
we can.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Los dioses no protegen a los insensatos.  Éstos reciben protección de
otros insensatos mejor dotados" (Luis Wu, Mundo Anillo)