Re: Potential ABI breakage in upcoming minor releases

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Potential ABI breakage in upcoming minor releases
Date: 2024-11-14 18:20:38
Message-ID: CABOikdPSO=pdAeRJ-_tS2EG=88bKbB=hZt9ZJS6p6GKcMTiLtg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Nov 14, 2024 at 9:43 PM Peter Eisentraut <peter(at)eisentraut(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2024-11-14 18:26:58 Re: Potential ABI breakage in upcoming minor releases
Previous Message Matthias van de Meent 2024-11-14 18:14:18 Re: SQL:2011 application time