Date: Tue, 26 Nov 2024 05:16:05 +0000
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>
Subject: Re: Potential ABI breakage in upcoming minor releases
Message-ID: <Z0VZlX3ZKwmY9zl+@ip-10-97-1-34.eu-west-3.compute.internal>
References: <CAJ7c6TPcUJq_Bwo69f6ysRA1UbmSh_hOOEzJ2EvM0cW=3VEh5w@mail.gmail.com>
 <CAFMSG9Hy-2-8tfmmKy7noCbA3Yn1UY2SFUwYj7wHODTO8gDm8w@mail.gmail.com>
 <CAJ7c6TMCc85YoiSKex5Sztz6bEmV-0YqL7FY=_MxxcyoMGTDfQ@mail.gmail.com>
 <2443809.1731683394@sss.pgh.pa.us>
 <20241115175223.68.nmisch@google.com>
 <2483970.1731702561@sss.pgh.pa.us>
 <2500050.1731705196@sss.pgh.pa.us>
 <900DE0C9-48C4-474C-BDC9-AD495D8D3F59@justatheory.com>
 <2638276.1731717056@sss.pgh.pa.us>
 <1576843.1732586210@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1576843.1732586210@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/Z0VZlX3ZKwmY9zl%2B%40ip-10-97-1-34.eu-west-3.compute.internal>
Precedence: bulk

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