Horton

Re: Potential ABI breakage in upcoming minor releases

Pavan Deolasee <pavan.deolasee@gmail.com>

View thread
From: Pavan Deolasee <pavan.deolasee@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Noah Misch <noah@leadboat.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-11-14T18:20:38Z
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.

On Thu, Nov 14, 2024 at 9:43 PM Peter Eisentraut <peter@eisentraut.org>
wrote:

> On 14.11.24 15:35, Noah Misch wrote:
> > The postgr.es/c/e54a42a standard would have us stop here.  But I'm open
> to
> > treating the standard as mistaken and changing things.
>
> That text explicitly calls out that adding struct members at the end of
> a struct is considered okay.


I think that assumption is ok when the struct is allocated by core and
passed to the extension. But if the struct is allocated (static or dynamic)
and passed to the core, we have to be extra careful.


> But thinking about it now, even adding
> fields to the end of a node struct that extensions allocate using
> makeNode() is an ABI break that is liable to cause all affected
> extensions to break in a crashing way.
>

Memory corruption issues can be quite subtle and hard to diagnose. So if
wrapping a new release is an option, I would vote for it. If we do that,
doing it for every impacted version would be more prudent. But I don't know
what are the policies around making a new release.

Thanks,
Pavan