docker-library
got collation warning after pull of latest postgres:17
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.
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 (https://github.com/docker-library/postgres/pull/1098) and now (https://github.com/docker-library/postgres/pull/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 (https://github.com/docker-library/postgres/issues/1099#issuecomment-2563370352). A dump/restore should always produce the correct results.
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.
Hmm, so perhaps I should update https://github.com/docker-library/postgres/pull/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.
Sorry, that was not as constructive as I intended it to be. :bow:
I am very open to feedback, suggestions, and ideas for how we can improve this. :heart:
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).