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: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
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-26T18:17:29Z
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.

Bertrand Drouvot <bertranddrouvot.pg@gmail.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