public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bertrand Drouvot <[email protected]>
To: Tom Lane <[email protected]>
Cc: David E. Wheeler <[email protected]>
Cc: Noah Misch <[email protected]>
Cc: Aleksander Alekseev <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Marco Slot <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Pavan Deolasee <[email protected]>
Subject: Re: Potential ABI breakage in upcoming minor releases
Date: Tue, 26 Nov 2024 05:16:05 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CAJ7c6TPcUJq_Bwo69f6ysRA1UbmSh_hOOEzJ2EvM0cW=3VEh5w@mail.gmail.com>
<CAFMSG9Hy-2-8tfmmKy7noCbA3Yn1UY2SFUwYj7wHODTO8gDm8w@mail.gmail.com>
<CAJ7c6TMCc85YoiSKex5Sztz6bEmV-0YqL7FY=_MxxcyoMGTDfQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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_backpatchi...
>
> 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.inte...
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
view thread (26+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Potential ABI breakage in upcoming minor releases
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox