PostgreSQL November 2026 minor releases: update the server and extensions together
PostgreSQL 18.7, 17.12, 16.16, 15.20 and 14.25 are out today. If you use the PGDG RPM repositories (yum.postgresql.org or zypp.postgresql.org), please update PostgreSQL and all of your extensions in the same transaction this time. Do not update the server today and the extensions next month, and do not hold one back while the other moves.
This release is different from a usual minor release. It contains the fix for CVE-2026-6460, and that fix reaches into the extensions too. So we rebuilt every extension in the repositories against the new minor releases. That covers every package built separately for each PostgreSQL version, on all supported RHEL / Rocky Linux / AlmaLinux, Fedora, Amazon Linux, SLES and openSUSE Leap versions. The rebuilt packages are released together with the new minors.
Why the extensions are tied to the minor release now
The CVE-2026-6460 fix (commit 245eb832f) adds versions for composite types. It changes how composite values are stored, and it changes the server's interface to extensions in two ways:
DatumGetHeapTupleHeader()used to be a macro. It is now a function in the server.heap_getattr()now calls the newheap_datum_check().
The headers are compiled into the extension, so this affects both directions:
- Old extension on a new server: the extension still loads and works. But it does not have the checks of the fix, so it may not be protected from the vulnerability. This is why we rebuilt everything.
- New extension on an old server: the extension now calls functions that the old server does not have. It fails to load with an "undefined symbol" error.
So a new server needs new extensions to be safe, and the new extensions need a new server to load at all. That is why they have to be updated together.
What changed in the packages
Until now, an extension package only required the PostgreSQL major version. From these rebuilds on, every compiled extension requires at least today’s minor release of its major version. For example, an extension built for PostgreSQL 18 now has:
Requires: postgresql18-libs >= 18.7
The server, client and contrib packages all require the exact same version of postgresql18-libs. So this one line ties the extension to the whole installation: dnf or zypper cannot install the new extension next to an old server.
The extensions also build-require the matching -devel version. A build on a builder that does not have the new minor yet fails, instead of quietly producing a package that is linked against the old headers.
What you should do: one update, everything at once
Update PostgreSQL and the extensions in one transaction:
sudo dnf update # RHEL, Rocky Linux, AlmaLinux, Fedora, Amazon Linux
sudo zypper update # SLES, openSUSE Leap
The dependencies take care of this in most cases. Even sudo dnf update postgis36_18 alone now pulls the new server, client and libs with it. When the server package is updated, it restarts a running PostgreSQL service (systemctl try-restart), so plan a short downtime, as with every minor release.
If you run several major versions on one machine, update all of them. Each major version has its own minor release today and its own rebuilt extensions.
Things to avoid:
- Holding the server back. With
dnf versionlockor anexclude=postgresql18*line, dnf will not update the extensions either. It reports that their dependencies cannot be resolved. Your current extensions keep working on your current minor, but you get neither the security fix nor the new extension builds. - Holding the extensions back. If you exclude an extension and update only the server, the old extension still loads, but it is built without the checks of the fix. Update it with the server.
- Skipping the broken ones.
--skip-brokenand--nobestleave you with a half-updated system. If dnf complains, find out which lock or exclude causes it instead. - Copying RPMs between machines. An extension RPM built today does not load on a server that is still on 18.6 or older. Install from the repository, together with the server.
- Leaving the old server running. If your service is not managed by the
postgresql-18unit, for example under Patroni or a custom unit, restart PostgreSQL yourself right after the update. Until then, the old server binary is running, and a new extension library loaded into it can fail with "undefined symbol".
In short: treat PostgreSQL and its extensions as one unit, and update them together.
What else the rebuilds found
Rebuilding every extension against the new minors also ran their regression tests against them. Three packages needed fixes:
- pg_repack: on PostgreSQL 14 to 18, the new minors store a
pg_attver=Nentry inpg_attribute.attoptions. One test lists the column options, so its expected output no longer matched. We now leavepg_attverout of that check; the test still checks that the column options are kept. - rum: one query in the
rum_validatetest passes a composite value to a deliberately broken operator class. Its result was never defined, and it now fails with "unrecognized operator". We removed only that query; the rest of the test still runs. - pllua: this one was a real bug, not a test problem. The new minors also fix CVE-2026-120143:
SPI_finish()now drops the cursors that use a trigger's transition tables. pllua closes its SPI connection after every call, so a trigger function that loops over a transition table withspi.rows()crashed the server. Our packages carry a fix, and I sent it upstream as pllua/pllua#19.
The pllua crash is one more reason to update everything together: the old pllua package on a new server crashes in exactly this case.
PostgreSQL 14 and reporting problems
PostgreSQL 14.25 is the final release of PostgreSQL 14. Its packages get today's fix and rebuilds too, but nothing after this. Please plan your upgrade to a newer major version.
Both websites have a news item with the details: yum.postgresql.org and zypp.postgresql.org.
If an update fails to resolve, or an extension fails to load after the update, please open an issue on our issue tracker. Please include the output of rpm -qa | grep postgres and the exact error message.
