Re: Potential ABI breakage in upcoming minor releases

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: "David E(dot) Wheeler" <david(at)justatheory(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Marco Slot <marco(dot)slot(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Christoph Berg <myon(at)debian(dot)org>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
Subject: Re: Potential ABI breakage in upcoming minor releases
Date: 2024-11-26 18:17:29
Message-ID: 1701256.1732645049@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> writes:
> On Mon, Nov 25, 2024 at 08:56:50PM -0500, Tom Lane wrote:
>> ... (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

Mumble ... that seems too simplistic to me. Admittedly,
I can't offhand think of an inter-platform variation that
would move field offsets by something other than a multiple
of 4 bytes, so maybe it's correct.

In any case, I think the purpose of these notes is just to remind
people of issues to think about, not to provide complete solution
recipes, so I'd rather not go into that much detail.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-11-26 18:24:35 Re: Potential ABI breakage in upcoming minor releases
Previous Message Robert Haas 2024-11-26 18:09:16 Re: Misleading "epoll_create1 failed: Too many open files"