Horton

Re: Potential ABI breakage in upcoming minor releases

Bertrand Drouvot <bertranddrouvot.pg@gmail.com>

View thread
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David E. Wheeler" <david@justatheory.com>, 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-26T05:16: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.

Hi,

On Mon, Nov 25, 2024 at 08:56:50PM -0500, Tom Lane wrote:
> [ getting back to the document-ABI-breakage-rules-better topic ... ]
> 
> I wrote:
> > 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.
> 
> I remembered where that's documented:
> 
> https://wiki.postgresql.org/wiki/Committing_checklist#Maintaining_ABI_compatibility_while_backpatching
> 
> I propose rewriting and expanding that:
> 
> * Don't change the contents of globally-visible structs, specifically
>   not the offsets of existing fields.  If you must add a new field,
>   the very best way is to put it into existing alignment padding
>   between fields.  (But consider both 32-bit and 64-bit cases when
>   deciding what is "padding".)

What about providing a decision table to help considering for 32-bit, something
like (proposed in [1])?

64-bit hole size | use on 32-bit?
-----------------|---------------
<=3 bytes        | safe to use
4 bytes          | don't use
5-7 bytes        | use first (hole_size - 4) bytes only

[1]: https://www.postgresql.org/message-id/flat/ZzcR%2BoQmUOIm6RVF%40ip-10-97-1-34.eu-west-3.compute.internal#08182ae6a6719632acf52fe4d90e9778

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com