| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Nathan Bossart <nathandbossart(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10 |
| Date: | 2026-04-08 17:24:29 |
| Message-ID: | CADkLM=fyg1gDtq7AH7N1yazJfdMSdeY8=TYrfDaGqT8hRCgzRw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-04-08 17:31:15 | Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10 |
| Previous Message | Andres Freund | 2026-04-08 17:22:41 | Re: Adding REPACK [concurrently] |