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: "David E. Wheeler" <david@justatheory.com>
Cc: Noah Misch <noah@leadboat.com>, 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-16T00:30:56Z
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.

"David E. Wheeler" <david@justatheory.com> writes:
> On Nov 15, 2024, at 16:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In other words, our current guidelines
>> for preserving ABI compatibility actually *created* this disaster,
>> because the HEAD change was fine from an ABI standpoint but what
>> was done in back branches was not.  So we do need to rethink how
>> that's worded.

> What bit is mis-worded? The guidance Peter committed[1] says that “PostgreSQL makes an effort to avoid server
> ABI breaks in minor releases.”

That text says exactly nothing about what specific code changes to
make or not make.  I'm not sure offhand where (or if) we have this
documented, but there's an idea that adding fields at the end of
a struct is safer ABI-wise than putting them in the middle.  Which
is true if you can't squeeze them into padding space.  Here, that
could have been done and probably should have.

The other bit of documentation we probably need is some annotation in
struct ResultRelInfo saying "do not change the sizeof() this struct
in back branches, period".

			regards, tom lane