Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10 - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10
Date
Msg-id CADkLM=fyg1gDtq7AH7N1yazJfdMSdeY8=TYrfDaGqT8hRCgzRw@mail.gmail.com
Whole thread
In response to Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10
List 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.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Adding REPACK [concurrently]
Next
From: Nathan Bossart
Date:
Subject: Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10