Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers@postgresql.org
Date: 2026-04-08T17:24:29Z
Lists: pgsql-hackers
> > > I wonder whether we ought to sunset some of that code too, and > > if so how to draw the line on minimum archive version to support. > I'm assuming that the need to restore such very old dumpfiles is forensic or compliance in nature, so we'd want to give people some recourse for those files going forward. > I guess people wanting to upgrade from > ancient versions can do it in multiple hops. +1 It would help if we provided some small documentation on how to do that. It could be as simple as a docbook table mapping various postgres versions to the highest version a) a live database can be pg_upgraded to and b) a dumpfile can be pg_restored to. But it could also include a script to re-dump an old dumpfile to a newer dump version. I'd be happy to take a swing at that if nobody else is interested. > At the same time, I > wouldn't want to do this every year. It's been 5 years since he last > time we did this, and that seems about the right interval. > +1 to a 5 year cadence. > I guess I'll have to teach the buildfarm's cross-version upgrade module > what old versions are supported by which release. > Which is a second use for that table I just proposed.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove pg_dump/pg_dumpall support for dumping from pre-v10 servers.
- 3a0a30884fd0 master landed
-
Remove pg_upgrade support for upgrading from pre-v10 servers.
- 14d841808307 master landed
-
Remove psql support for pre-v10 servers.
- 831bec45924a master landed
-
Run pgindent and pgperltidy for previous 3 commits.
- d69fdf79b8ba master landed