Horton
Menu

Thread

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.

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-08T15:47:27Z

    (This is for v20.)

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 30e7c175b81,
e469f0aaf3, and cf0cab868a).

From "git show --stat":
    16 files changed, 569 insertions(+), 1836 deletions(-)

Thoughts?

[0] https://postgr.es/m/d0316012-ece7-7b7e-2d36-9c38cb77cb3b%40enterprisedb.com

-- 
nathan

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-08T16:23:01Z

    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

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

    Andrew Dunstan <andrew@dunslane.net> — 2026-04-08T16:42:21Z

    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

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

    Corey Huinker <corey.huinker@gmail.com> — 2026-04-08T17:24:29Z

    >
> > 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.

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-08T17:31:15Z

    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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-04-08T17:55:30Z

    Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Apr 08, 2026 at 12:42:21PM -0400, Andrew Dunstan wrote:
>> On 2026-04-08 We 12:23 PM, Tom Lane wrote:
>>> 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.

Yeah.  In 64f3524e2 I said

    I did not remove the ability for pg_restore to read custom-format archives
    generated by these old versions (and light testing says that that does
    still work).  If you have an old server, you probably also have a pg_dump
    that will work with it; but you have an old custom-format backup file,
    that might be all you have.

That reasoning still holds, so we ought to be a bit more reluctant to
remove archive-version support than server-version support.  However,
carrying ancient code we can't test anymore isn't attractive either.

BTW, I think this is actually more complicated than just looking for
code that's conditional on K_VERS_x; there's not that much of that
anyway, if memory serves.  What could get rid of more code is looking
for places that support TOC entry types we no longer generate, or work
around bugs we no longer have.  Finding such places is tricky though.
A starting point might be to examine the code coverage report for
unexercised stanzas in pg_restore.

Another related point, which doesn't really concern this code-ectomy
project but is relevant to Corey's idea of making a table of supported
upgrade paths, is that we've also made server-side changes that affect
dump/restore compatibility.  The ones I found in a quick search
were v13's e58a59975, 84eca14bc, bb03010b9, but there are probably
more.

			regards, tom lane

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-04-08T18:04:02Z

    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

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-05-01T20:10:51Z

    I wrote a new set of patches on a plane a couple of weeks ago, but I forgot
to post them.  I'm not yet 100% positive I've got the changes to
rewrite_multixacts() in the pg_upgrade patch correct, but otherwise it's
pretty mechanical and straightforward.

-- 
nathan

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-05-06T21:47:15Z

    On Fri, May 01, 2026 at 03:10:51PM -0500, Nathan Bossart wrote:
> I wrote a new set of patches on a plane a couple of weeks ago, but I forgot
> to post them.  I'm not yet 100% positive I've got the changes to
> rewrite_multixacts() in the pg_upgrade patch correct, but otherwise it's
> pretty mechanical and straightforward.

Best I can tell, the rewrite_multixacts() changes are fine.  I also noticed
a couple of accidental removals of v11 stuff in the psql patch, which
should be fixed in the attached.

-- 
nathan

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

    Andrew Dunstan <andrew@dunslane.net> — 2026-05-16T12:00:25Z

    On 2026-05-06 We 5:47 PM, Nathan Bossart wrote:
> On Fri, May 01, 2026 at 03:10:51PM -0500, Nathan Bossart wrote:
>> I wrote a new set of patches on a plane a couple of weeks ago, but I forgot
>> to post them.  I'm not yet 100% positive I've got the changes to
>> rewrite_multixacts() in the pg_upgrade patch correct, but otherwise it's
>> pretty mechanical and straightforward.
> Best I can tell, the rewrite_multixacts() changes are fine.  I also noticed
> a couple of accidental removals of v11 stuff in the psql patch, which
> should be fixed in the attached.


Have we made a definite decision on this? If so, I will push the 
buildfarm change I have ready for it, so when we pull the trigger we 
don't get breakage.


cheers


andrew


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

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

    Tom Lane <tgl@sss.pgh.pa.us> — 2026-05-16T13:42:47Z

    Andrew Dunstan <andrew@dunslane.net> writes:
> Have we made a definite decision on this? If so, I will push the 
> buildfarm change I have ready for it, so when we pull the trigger we 
> don't get breakage.

I think we've agreed to do this for v20.  (I've not reviewed the
proposed patch, so that's not an endorsement of the patch details.)
Getting out ahead of that in the buildfarm would be a good thing.

			regards, tom lane

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-05-16T13:44:17Z

    On Sat, May 16, 2026 at 09:42:47AM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Have we made a definite decision on this? If so, I will push the 
>> buildfarm change I have ready for it, so when we pull the trigger we 
>> don't get breakage.
> 
> I think we've agreed to do this for v20.  (I've not reviewed the
> proposed patch, so that's not an endorsement of the patch details.)
> Getting out ahead of that in the buildfarm would be a good thing.

+1

-- 
nathan

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

    Andrew Dunstan <andrew@dunslane.net> — 2026-05-16T17:51:57Z

    On 2026-05-16 Sa 9:44 AM, Nathan Bossart wrote:
> On Sat, May 16, 2026 at 09:42:47AM -0400, Tom Lane wrote:
>> Andrew Dunstan <andrew@dunslane.net> writes:
>>> Have we made a definite decision on this? If so, I will push the
>>> buildfarm change I have ready for it, so when we pull the trigger we
>>> don't get breakage.
>> I think we've agreed to do this for v20.  (I've not reviewed the
>> proposed patch, so that's not an endorsement of the patch details.)
>> Getting out ahead of that in the buildfarm would be a good thing.
> +1
>


OK, I have pushed that. See 
<https://github.com/PGBuildFarm/client-code/commit/4c3ed0c37bbcaf427e61384bb351364ecae9b4d9>

crake will be immediately affected on HEAD. I'll make a new release when 
we branch the tree.


cheers


andrew


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

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-06-11T14:21:28Z

    rebased

-- 
nathan

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-06-29T15:16:40Z

    rebased

-- 
nathan

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

    Fujii Masao <masao.fujii@gmail.com> — 2026-06-30T03:36:39Z

    On Tue, Jun 30, 2026 at 12:16 AM Nathan Bossart
<nathandbossart@gmail.com> wrote:
>
> rebased

Thanks for updating the patches!

Regarding 0001 patch:

Wouldn't it make sense to document the minimum supported server
version also in the pg_dumpall docs?

    /*
     * We allow the server to be back to 9.2, and up to any minor release of
     * our own major version.  (See also version check in pg_dump.c.)
     */
    if (my_version != server_version_temp
        && (server_version_temp < 90200 ||
            (server_version_temp / 100) > (my_version / 100)))

Shouldn't this be updated as well?


Regarding 0002 patch:

- if (GET_MAJOR_VERSION(old_cluster.major_version) < 902)
+ if (GET_MAJOR_VERSION(old_cluster.major_version) < 10)

Shouldn't this be "< 1000" instead of "< 10"?

According to the following git grep results, there still seem to be
several code paths for pre-v10 support. Should those also be updated or
removed?

    $ git grep -E "GET_MAJOR_VERSION.* 9"
    src/bin/pg_upgrade/controldata.c:       if
(GET_MAJOR_VERSION(cluster->bin_version) <= 906)
    src/bin/pg_upgrade/controldata.c:       if
(GET_MAJOR_VERSION(cluster->major_version) <= 902)
    src/bin/pg_upgrade/controldata.c:                       else if
(GET_MAJOR_VERSION(cluster->major_version) >= 906)
    src/bin/pg_upgrade/controldata.c:       if
(GET_MAJOR_VERSION(cluster->major_version) <= 902)
    src/bin/pg_upgrade/server.c:
(GET_MAJOR_VERSION(cluster->major_version) <= 902) ?

    # --swap can't be used to upgrade from versions older than 10, so just skip
    # the test if the old cluster version is too old.
    if ($old->pg_version < 10 && $mode eq "--swap")

In pg_upgrade/t/006_transfer_modes.pl, shouldn't this simply be
"if ($old->pg_version < 10)" so that the test is skipped whenever
the old cluster is pre-v10?


Regarding 0003 patch:

    /*
     * These object types were introduced later than our support cutoff of
     * server version 9.2.  We use the VersionedQuery infrastructure so that
     * we don't send certain-to-fail queries to older servers.
     */

In psql/tab-complete.in.c, shouldn't this comment be updated as well?


Overall, the following git grep results seem to suggest that there are several
comments referring to pre-v10 support that may also need updating:

    $ git grep " 9\.[0-6]" | grep -E "pg_dump|pg_upgrade|psql" | grep -v "\.po:"

Regards,

-- 
Fujii Masao

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-06-30T20:18:51Z

    On Tue, Jun 30, 2026 at 12:36:39PM +0900, Fujii Masao wrote:
> Thanks for updating the patches!

Appreciate the review.

> Regarding 0001 patch:
> 
> Wouldn't it make sense to document the minimum supported server
> version also in the pg_dumpall docs?

Yes, I think so.  However, since that's an additive change and not directly
related to $subject, I'd like to tackle it separately.  Folks might have
preferences on the wording.

>     /*
>      * We allow the server to be back to 9.2, and up to any minor release of
>      * our own major version.  (See also version check in pg_dump.c.)
>      */
>     if (my_version != server_version_temp
>         && (server_version_temp < 90200 ||
>             (server_version_temp / 100) > (my_version / 100)))
> 
> Shouldn't this be updated as well?

Oops, yes.

> Regarding 0002 patch:
> 
> - if (GET_MAJOR_VERSION(old_cluster.major_version) < 902)
> + if (GET_MAJOR_VERSION(old_cluster.major_version) < 10)
> 
> Shouldn't this be "< 1000" instead of "< 10"?

Yes.

> According to the following git grep results, there still seem to be
> several code paths for pre-v10 support. Should those also be updated or
> removed?
> 
>     $ git grep -E "GET_MAJOR_VERSION.* 9"
>     src/bin/pg_upgrade/controldata.c:       if
> (GET_MAJOR_VERSION(cluster->bin_version) <= 906)
>     src/bin/pg_upgrade/controldata.c:       if
> (GET_MAJOR_VERSION(cluster->major_version) <= 902)
>     src/bin/pg_upgrade/controldata.c:                       else if
> (GET_MAJOR_VERSION(cluster->major_version) >= 906)
>     src/bin/pg_upgrade/controldata.c:       if
> (GET_MAJOR_VERSION(cluster->major_version) <= 902)
>     src/bin/pg_upgrade/server.c:
> (GET_MAJOR_VERSION(cluster->major_version) <= 902) ?

Fixed.  I thought I had handled these, but apparently they got lost
somewhere.

>     # --swap can't be used to upgrade from versions older than 10, so just skip
>     # the test if the old cluster version is too old.
>     if ($old->pg_version < 10 && $mode eq "--swap")
> 
> In pg_upgrade/t/006_transfer_modes.pl, shouldn't this simply be
> "if ($old->pg_version < 10)" so that the test is skipped whenever
> the old cluster is pre-v10?

I think we can remove it entirely.  We don't block for <v9.2 today, so I
see no need to make it robust against invalid test setups.

> Regarding 0003 patch:
> 
>     /*
>      * These object types were introduced later than our support cutoff of
>      * server version 9.2.  We use the VersionedQuery infrastructure so that
>      * we don't send certain-to-fail queries to older servers.
>      */
> 
> In psql/tab-complete.in.c, shouldn't this comment be updated as well?

This also got lost along the way.  Fixed.

> Overall, the following git grep results seem to suggest that there are several
> comments referring to pre-v10 support that may also need updating:
> 
>     $ git grep " 9\.[0-6]" | grep -E "pg_dump|pg_upgrade|psql" | grep -v "\.po:"

I didn't see anything else that I thought obviously needed to be changed.
Please let me know if you feel otherwise.

-- 
nathan

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-07-01T15:55:01Z

    On Tue, Jun 30, 2026 at 03:18:51PM -0500, Nathan Bossart wrote:
> I didn't see anything else that I thought obviously needed to be changed.
> Please let me know if you feel otherwise.

FTR I'm planning to commit this tomorrow.

-- 
nathan

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

    Nathan Bossart <nathandbossart@gmail.com> — 2026-07-02T18:11:06Z

    On Wed, Jul 01, 2026 at 10:55:01AM -0500, Nathan Bossart wrote:
> FTR I'm planning to commit this tomorrow.

Committed.

-- 
nathan