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 →
  1. Remove pg_dump/pg_dumpall support for dumping from pre-v10 servers.

  2. Remove pg_upgrade support for upgrading from pre-v10 servers.

  3. Remove psql support for pre-v10 servers.

  4. Run pgindent and pgperltidy for previous 3 commits.