Proposal: Document ABI Compatibility - Mailing list pgsql-hackers

From David E. Wheeler
Subject Proposal: Document ABI Compatibility
Date
Msg-id 5DA9F9D2-B8B2-43DE-BD4D-53A4160F6E8D@justatheory.com
Whole thread Raw
Responses Re: Proposal: Document ABI Compatibility
List pgsql-hackers
Hackers,

At the PGConf Unconference session on improving extension support in core, we talked quite a bit about the recent
anxietyamong extension developers about a lack of an ABI compatibility guarantee in Postgres. Yurii Rashkovskii did a
littleheader file spelunking and talked[1] about a few changes in minor version releases, including to apparent field
orderin structs. Jeremy Schneider posted the example on Twitter[2], and Peter G replied[3]: 

> You must be referring to my commit 714780dc. The new field is stored within alignment padding (though only on back
branches).Has this been tied to a known problem? 

At the Unconference, Tom Lane said that this approach is pretty well drilled into the heads of every committer, and new
onespick it up through experience. The goal, IIUC, is to never introduce binary incompatibilities into the C APIs in
minorreleases. This standard would be good to document, to let extension developers know exactly what the guarantees
are.

I’m happy to start a doc patch to add an ABI compatibility guarantee (presumably in xfunc.sgml), but want to be sure
thedetails are right, namely: 

* There are no source or binary compatibility guarantees for major releases.

* The ABI is guaranteed to change only in backward compatible ways in minor releases. If for some reason it doesn’t
it’sa bug that will need to be fixed. 

This ensures that an extension compiled against an earlier minor release will continue to work without recompilation on
laterminor releases of the same major version. 

But if I understand correctly, the use of techniques like adding a new field in padding does not mean that extensions
compiledon later minor releases will work on earlier minor releases of the same major version. Unless, that is, we can
providea complete list of things not to do (like make use of padding) to avoid it. Is that feasible? 

Are there other details it should include?

Thanks,

David

[1]: https://www.pgevents.ca/events/pgconfdev2024/schedule/session/14
[2]: https://x.com/jer_s/status/1785717368804815026
[3]: https://x.com/petervgeoghegan/status/1785720228237717627




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Build with LTO / -flto on macOS
Next
From: Nathan Bossart
Date:
Subject: Re: allow changing autovacuum_max_workers without restarting