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

Nathan Bossart <nathandbossart(at)gmail(dot)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