New policies on PostgreSQL operand images

[gbartolini]

The official Docker image for Postgres project has removed support for Debian 11 (bullseye) in favour of Debian 13 (trixie). See: PR #1354. However, “bullseye” is maintained for another year (31 August 2026).

The removal of “bullseye” from the official Docker images of Postgres creates an unexpected and unprecedented (though probably foreseeable) problem with the default CloudNativePG Postgres container images: although we have prepared the ground for the new set of images, called “minimal” and “standard”, and built through “bake” directly from Debian base images, the default images are still based on the “bullseye” official Docker images.

This epic keeps track of all the related issues that need to be solved in order to remove the legacy way of building images and rely solely on bake, while providing clear information on the supportability of distributions, PostgreSQL versions, and tags.

[ardentperf]

All of the CNPG images (old system and also the newer minimal/standard) will have to deal with lifecycle of the base containers they build on. Debian major versions will always be de-supported at some point.

Personal opinion: i think it's fine to drop bullseye support from system images now, rather than CNPG project taking on extra work to keep them working for one more year.

I don't think it's a "policy" question here because there's really no sensible way CNPG could support something when the upstream source no longer supports it. So it's ok to take a position that CNPG builds system images for the official docker postgres builds that are available, and CNPG builds minimal/standard images for the official debian builds that are available. Honestly this is just more incentive for people to move to minimal/standard from system, which seems ok.

From my perspective, the main driver of caution around debian OS changes is collation.

FWIW - the collation torture test did not detect any changes between bullseye and bookworm. It's not a mathmatical proof but it's got decent coverage. So at least we know there aren't any big obvious far-reaching corruptions coming with bookworm updates!

https://github.com/ardentperf/glibc-unicode-sorting#user-content-debian

Users need to update their OS images over time. This is a well-known problem in core Postgres that is not unique to CNPG. Users with multi-TB databases have exactly the same risks if they want to use backup/restore to upgrade to a new OS/server, rather than a slow logical pg_dump/load.

From my perspective, the best way to create a "safe-by-default" experience is to simply make everything C collation by default, and have users "accept the risk" to use linguistic collation.

CNPG already defaults to C collation at the database level, one thing that would be nice is if with pg17+ we could default to the builtin provider instead of libc. But I think CNPG is already in the right place with C collation by default.

My wishlist for core postgres "safe-by-default" experience:

• GUC to block OS linguistic collation by default (would need an upstream PG contribution for this), so that users need to either explicitly install ICU or explicitly update the GUC if they want to use linguistic collation. By default, allow only C collation from the OS libc. Ideally people use ICU and not the OS.
• GUC to block the use of both OS and ICU linguistic collation as a database default, allowing it only at the table/column/query level. This way, users have an easy way to query the system catalog and get a complete list of objects that need to be rebuilt with OS and ICU updates.
• GUC to have the collation mismatch message be an ERROR instead of a WARNING. 🙂 On the first startup after an OS change, users can change this GUC to start up the DB and rebuild indexes, then change it back for normal operations.

ofc. the well-known problem with my argument for C collation by default is that it's terrible for a bunch of languages that are not English! this is why it's not an easy problem to solve in general. folks in france and japan and brazil and china are just kinda in a bind; on one hand it's annoying to add collation clauses to all your tables but on the other hand it's also annoying to have a panic attack every year when you worry about whether the new debian release will silently corrupt your indexes. really a shame. wasn't a problem for timezones because nobody builds indexes on local timestamps... but for some reason people seem to want indexes on their generic string data...