bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10

Nathan Bossart <nathandbossart@gmail.com> writes:

I've brought this up a couple times in the past ~year, so here's a patch.
Supporting versions as old as v9.2 has become quite cumbersome, requiring
various version-specific branches and hacks. I believe our current policy
is that we support at least 10 previous major versions [0]. For reference,
we last bumped the minimum to v9.2 in 2021 (commits 30e7c175b 81,
e469f0aaf3, and cf0cab868a).

I'm on board with this for v20, but as a matter of reviewing the
patch: it'd be easier if you separated it into two steps, one that
does the actual changes but doesn't reindent anything, and then a
separate application of pgindent. As this diff stands, there's an
awful lot of noise resulting from outdenting no-longer-conditional
code, which has to be reviewed by hand but it could be checked
mechanically if you left it to a "this just applies pgindent" step.

Looking at the commit log, I was struck by my comment in 30e7c175b:

(As in previous changes of
this sort, we aren't removing pg_restore's ability to read older
archive files ... though it's fair to wonder how that might be
tested nowadays.)

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.

BTW, see also 492046fa9.

regards, tom lane

On 2026-04-08 We 12:23 PM, Tom Lane wrote:

Nathan Bossart <nathandbossart@gmail.com> writes:

I've brought this up a couple times in the past ~year, so here's a patch.
Supporting versions as old as v9.2 has become quite cumbersome, requiring
various version-specific branches and hacks. I believe our current policy
is that we support at least 10 previous major versions [0]. For reference,
we last bumped the minimum to v9.2 in 2021 (commits 30e7c175b 81,
e469f0aaf3, and cf0cab868a).

I'm on board with this for v20, but as a matter of reviewing the
patch: it'd be easier if you separated it into two steps, one that
does the actual changes but doesn't reindent anything, and then a
separate application of pgindent. As this diff stands, there's an
awful lot of noise resulting from outdenting no-longer-conditional
code, which has to be reviewed by hand but it could be checked
mechanically if you left it to a "this just applies pgindent" step.

Looking at the commit log, I was struck by my comment in 30e7c175b:

(As in previous changes of
this sort, we aren't removing pg_restore's ability to read older
archive files ... though it's fair to wonder how that might be
tested nowadays.)

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.

BTW, see also 492046fa9.

I'm on board, if for no other reason than that it will shorten some of
my animals' buildfarm runs. I guess people wanting to upgrade from
ancient versions can do it in multiple hops. 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.

I guess I'll have to teach the buildfarm's cross-version upgrade module
what old versions are supported by which release.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

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.

On Wed, Apr 08, 2026 at 12:42:21PM -0400, Andrew Dunstan wrote:

On 2026-04-08 We 12:23 PM, Tom Lane wrote:

I'm on board with this for v20, but as a matter of reviewing the
patch: it'd be easier if you separated it into two steps, one that
does the actual changes but doesn't reindent anything, and then a
separate application of pgindent. As this diff stands, there's an
awful lot of noise resulting from outdenting no-longer-conditional
code, which has to be reviewed by hand but it could be checked
mechanically if you left it to a "this just applies pgindent" step.

Will do. There's also various code consolidation throughout, so I suspect
this will become ~3 patches in the end.

Looking at the commit log, I was struck by my comment in 30e7c175b:

(As in previous changes of
this sort, we aren't removing pg_restore's ability to read older
archive files ... though it's fair to wonder how that might be
tested nowadays.)

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.

K_VERS_1_12 was added in 2010 for v9.0, and K_VERS_1_13 was added in 2018
for v11. The latter is within our 10 release window for pg_dump, etc., and
the former is well beyond it. So, K_VERS_1_12 is probably the latest we
could bump it to. I suspect that'd be fine, but we might still want to
consider choosing an earlier version out of an abundance of caution.
Perhaps our policy could be something like past-15-major-releases for
pg_restore.

BTW, see also 492046fa9.

Noted.

I'm on board, if for no other reason than that it will shorten some of my
animals' buildfarm runs. I guess people wanting to upgrade from ancient
versions can do it in multiple hops. 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.

Yeah, I think this is where we ultimately landed in a previous discussion
on Discord.

--
nathan

On Wed, Apr 08, 2026 at 01:24:29PM -0400, Corey Huinker wrote:

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.

I like these ideas. IMHO this helps us be reasonably aggressive about
removing support for ancient versions while still providing a lifeboat when
folks using those ancient versions decide to upgrade.

--
nathan