Edit 11:54am Pacific Time: just realized Devrim Gunduz published a blog this morning on the same topic. [His blog is better than mine and more thorough]… just start there :)
Postgres API and ABI stability has been a topic of discussion for a long time. To understand why this matters so much, start with Dave Stokes recent blog post [Is PostgreSQL Really Winning Part 2: The Evidence Beyond the Rankings]. It’s fundamentally about “a slow core with a fast edge is a pretty good design” and how the Postgres extension API enables an amazing ecosystem around Postgres.
The official postgres docs have [guidance on API/ABI stability], and for a bit of extra background check out [David Wheeler’s 2024 post-pgconf blog], and EnterpriseDB’s [explainer about the Postgres 17.1 ABI breakage].
The postgres community works really hard not to break ABI compatibility because it means that a bunch of extensions won’t interoperate between minors. But sadly this was another of the rare cases where it was needed… this time as a result of CVE-2026-6460 (just one of many CVEs in the GIANT stack that 18.7 contains).
It’s explicit in the release notes and it’s the very first bullet point. https://www.postgresql.org/docs/release/18.7
Introduce versioning logic to permit detection of composite datums that don’t match the tuple descriptor we wish to interpret them with. For full protection, this change requires rebuilding C-language extensions, and there are some extensions that will require source-code changes. If necessary, the new composite_type_mismatch server parameter can be used to disable these checks, but doing so carries security risks.
ABI changes can be a pain for Postgres users. It means that extensions (which are packaged and distributed separately) might need to be upgraded exactly in lockstep with the Postgres minor bugfix update itself. One unfortunate side-effect of the Postgres model: Postgres 18.7 has important CVE fixes – but end users also rely on extensions, not just core. People using extensions can only upgrade to 18.7 and get those CVE fixes as long as their extensions also continue to work.
Edit: read Devrim’s blog – RPM packaging now adds a header to require a specific minor. I haven’t checked Debian ecosystem yet but it might also be addressing this.
From some initial looking, I think the Postgres core changes are compatible with older extensions, but newer updated extensions will not be backwards compatible because they are using a newer internal interface. So probably core needs to be updated first, and then extensions – and users need to be careful they don’t accidentally get updated extension packages before getting the core postgres packages through their update channels.
I’m doing a lot of work around extensions for CloudNativePG on Kubernetes and I saw a few of my own extension build pipelines broke today due to updates not happening in lockstep – for example Postgres extensions AGE, credcheck and pg_cron have already released new versions which don’t work at all on version 18.6 of Postgres! (In my pipelines the updated extensions arrived before updated Postgres itself.) Working on my pipelines now, to make sure things are updating in lockstep. Might take a day or two for core and extension updates to flow through various build channels.
Postgres users – manage this next minor update carefully; make sure you coordinate updates of your extensions and database.
Discussion
No comments yet.