Ardent Performance Computing

Latest Post

Postgres 18.7 Debian and Redhat Packagers Protect You

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 incompatible extension and server versions.

The people who need to really be careful are those who don’t use the packaging ecosystem, and who build and install extensions (and/or the database) from source. If you manage your own build/CI for postgres ecosystem code then you should be busy next week dealing with this latest Postgres minor release.