Just a short & quick follow-up to [yesterdays blog] before I run out the door.
I hadn’t been paying attention, and yesterday’s postgres release had a few surprises for me. I’m catching up now.
First: read [Devrim’s blog] and [Lukas’ 5-minutes-of-postgres] for the TLDR.
Second: I had this in yesterday’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.”
I took a quick look this morning, and Debian packaging does have the same protection.
This matters because lots of people won’t upgrade Postgres today (even though we tell them to). Next week they will try to install some new extension, and their OS packager will try to pull the latest version. Devrim and Christoph (two of our primary Postgres packagers 
) have ensured that the packaging systems will protect you from a bad installation.
On Debian:
apt-mark hold postgresql-18 apt-get install -y postgresql-18-cron Key output (installation fails): postgres (PostgreSQL) 18.6 (Debian 18.6-1.pgdg12+2) postgresql-18-cron : Depends: postgresql-18 (> 18.7) but 18.6-1.pgdg12+2 is to be installed E: Unable to correct problems, you have held broken packages. ... Allow upgrades: apt-mark unhold postgresql-18 apt-get install -y postgresql-18-cron postgres --version Key output: The following packages will be upgraded: libpq5 postgresql-18 postgresql-18-jit postgresql-client-18 Setting up postgresql-18 (18.7-1.pgdg12+2) ... Setting up postgresql-18-cron (1.6.8-1.pgdg12+3) ... ... Package metadata: apt-cache show postgresql-18-cron Key output for selected candidate: Version: 1.6.8-1.pgdg12+3 Depends: postgresql-18 (>> 18.7), libc6 (>= 2.14), libpq5 (>= 9.0~) On Rocky:
Try unversioned extension installation with PostgreSQL upgrades blocked: dnf install -y --exclude='postgresql18*' pg_cron_18 Key output (installation fails): Problem: package pg_cron_18-1.6.8-4PGDG.rhel9.8.x86_64 from pgdg18 requires postgresql18-libs(x86-64) >= 18.7, but none of the providers can be installed - cannot install the best candidate for the job - package postgresql18-libs-18.7-1PGDG.rhel9.8.x86_64 from pgdg18 is filtered out by exclude filtering ... Allow upgrades (the exclusion above applies only to that command): dnf install -y pg_cron_18 rpm -q postgresql18-server pg_cron_18 rpm -q --requires pg_cron_18 Key output: Installing: pg_cron_18 x86_64 1.6.8-4PGDG.rhel9.8 Upgrading: postgresql18 x86_64 18.7-1PGDG.rhel9.8 postgresql18-libs x86_64 18.7-1PGDG.rhel9.8 postgresql18-server x86_64 18.7-1PGDG.rhel9.8 postgresql18-server-18.7-1PGDG.rhel9.8.x86_64 pg_cron_18-1.6.8-4PGDG.rhel9.8.x86_64 ... Relevant RPM requirements: postgresql18-libs(x86-64) >= 18.7 postgresql18-server Most people running Postgres on Kubernetes today are building their own container images with extensions built into their custom container image. The most common way to build these is to directly use the Debian packages. The packaging protections above will also protect these users – if your container builds successfully, you have the right version combination.
CloudNativePG offers extension containers for Postgres 18 and newer. If you use CNPG extension catalogs then you’ll be covered because they are effectively rolling release; yesterday we made sure that the extension catalogs had the latest versions of both core postgres and all extensions – you always get the latest PG minor and the latest extension versions.
However if you manually select and pin extension container digest/version independently of your Postgres server digest/version, then it will be your responsibility ensure you don’t mix a newer extension version with an older server version.
