got collation warning after pull of latest postgres:17

[neiaberau]

I was using for some persisted test database postgres:17 image

After the most recent pull of the image and restart, I got for a persisted db:
DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

I assume this is due to postgres:17 moved to using debian trixi, as after restarting with image postgres:17-bookworm no more warnings are displayed.
(hostsystem is bullseye, maybe also related)

I do know that latest images are almost always not a good idea, but somehow I always associated this to the main application, not an underlying change of os system used in a Dockerfile.

But ok, my bad.
I only reported this so others are aware. If confirmed, and not my error, then maybe a warning on the main info page on https://hub.docker.com/_/postgres will help others.

[stuartherbert]

Can confirm the problem here too.

[yosifkit]

Yeah, this is caused by the images moving to the next major Debian release, Trixie.

We only support postgres images on two suites of Debian at a time. As we have in the past (#1098) and now (#1354), we move to the newest Debian release and drop the oldest. This also means that image tags without a Debian suite qualifier (e.g., postgres:17) move to the newest release.

I'd recommend not using tags without a Debian suite qualifier (-bookworm and -trixie) since then you can control when a major OS version bump happens for you. The plain tags will likely change again in a few years when Debian Forky is released. We maintain postgres images on the two most recent releases of Debian so that users have time to migrate.

---

TL;DR: use Debian suite qualified names like postgres:17-bookworm until you are ready for postgres:17-trixie. Only use plain tags (like postgres:17) for testing/dev or be prepared to handle changes at the next Debian stable suite release.

---

Since you have this on a test database, (after a backup) you could use it to test if the recommended ALTER DATABASE postgres REFRESH COLLATION VERSION is enough but perhaps that will cause stability issues (#1099 (comment)). A dump/restore should always produce the correct results.

[gwenshap]

While I understand the "two debian images" at a time, breaking collation (essentially breaking people's database behavior and possibly corrupting indexes) in a minor version upgrade is a very poor decision.

People trust that minor upgrades version upgrades will not break anything - and the expectation extends to the containers.

[tianon]

Hmm, so perhaps I should update #1294 to deprecate all generic aliases and force users to opt into a specific OS release? 🤔😬

That seems kind of hostile, but if that's what PostgreSQL requires users to do, there's not much we can do about it except try to reflect it accurately. 😕😞

However, to be clear, the minor version is not our minor version - it's reflective of the PostgreSQL minor version, so we don't make any breaking or non-breaking promises if all you've pinned to is a minor version number; our only promise in that case is that you'll receive a build of PostgreSQL at that minor version.

[tianon]

Sorry, that was not as constructive as I intended it to be. 🙇

I am very open to feedback, suggestions, and ideas for how we can improve this. ❤️

We have some battling constraints here that make the "best" answer less than obvious -- the biggest one is that a given PostgreSQL major version is typically supported for longer than the given OS release underneath it, which is normally a good relationship between those support windows but works against us here (ie, if we "pinned" to a specific OS release for the generic tags, the OS release would go out of support before the PostgreSQL release did, leaving users with an unsupported and unsupportable image).