That is mostly an issue with the official docker image, not a PostgreSQL issue. Upgrading to a new major is easy if you use the Debian packages and is fine with a couple of minutes downtime. There is no reason a docker image could not do the same.

The issue with PostgreSQL which the Debian packages handle fine but the Docker Hub's image does not is that you need both the executables for the old and the new major version of PostgreSQL when upgrading. This just works with Debian packages but not with the Docker image.

▲

Sesse__ 17 hours ago | parent | next [-]

> That is mostly an issue with the official docker image, not a PostgreSQL issue.

I wish Docker would stop calling their unofficial Postgres images “official”. :-/ (They're “official Docker”, but not “official Postgres”. The naming is deeply misleading for everyone who is not a Docker expert.)

▲

ktosobcy a day ago | parent | prev [-]

I'm fully aware why it's an issue with official image. But even with debian (or any other "packaging") there are hoops to be hopped through due to said missing upgrade handling which IMHO is very annoying.

They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade. I (well, a lot of people judging from votes and comments in https://github.com/docker-library/postgres/issues/37 and stars in https://github.com/tianon/docker-postgres-upgrade) would love that, and only between subsequent version would be more than enough…

▲

mattashii 18 hours ago | parent | next [-]

> They do handle minor versions upgrade so the code handling upgrading is there but devs seems to be quite adamant against adding major version upgrade

Minor versions of PostgreSQL have constraints that major versions don't have; in that minor versions in principle don't see new features added. This allows minor versions of the same major release to run against the same data directory without modifications.

However.

Major versions add those new features, at the cost of changes to internals that show up in things like catalog layout. This causes changes in how on-disk data is interpreted, and thus this is incompatible, and unlike minor releases this requires specialized upgrade handling.

	▲	ktosobcy 18 hours ago \| parent [-]
		Well, yeah. But virtually all other software can peroform the data upgrad with single/new binary and only PostgreSQL requires old binaries to be available to run `pg_upgrade`...

▲

jeltz 16 hours ago | parent | prev [-]

I suggest you look into what pg_upgrade actually does because the "code handling upgrading" does not exist other than as pg_upgrade. And writing it would be a ton of work and would likely halt a lot of innovation in PostgreSQL and make it no longer a competitive database unless someone does a major re-architecting of PostgreSQL which likely would break all extensions.

The issue causing it is how PostgreSQL has implemented the system catalog.