Re: pg_dump versus ancient server versions

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: pg_dump versus ancient server versions
Date: 2021-10-25 12:29:24
Message-ID: bf20bbf7-e4e1-bf09-3c58-d772f53ef9bf@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 10/22/21 19:30, Tom Lane wrote:
> "David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
>> On Fri, Oct 22, 2021 at 3:42 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Anyway, I think the default answer is "revert 92316a458 and keep the
>>> compatibility goalposts where they are". But I wanted to open up a
>>> discussion to see if anyone likes the other approach better.
>> ... IMO, the bar for this kind of situation should be 10 releases at
>> most - 5 of which would be in support at the time the patch goes in. We
>> don't have to actively drop support of older stuff but anything older
>> shouldn't be preventing new commits.
> Yeah. I checked into when it was that we dropped pre-8.0 support
> from pg_dump, and the answer is just about five years ago (64f3524e2).
> So moving the bar forward by five releases isn't at all out of line.
> 8.4 would be eight years past EOL by the time v15 comes out.
>
> One of the arguments for the previous change was that it was getting
> very hard to build old releases on modern platforms, thus making it
> hard to do any compatibility testing. I believe the same is starting
> to become true of the 8.x releases, though I've not tried personally
> to build any of them in some time. (The executables I'm using for
> them date from 2014 or earlier, and have not been recompiled in
> subsequent platform upgrades ...) Anyway it's definitely not free
> to continue to support old source server versions.

But we don't need to build them on modern platforms, just run them on
modern platforms, ISTM.

Some months ago I built binaries all the way back to 7.2 that with a
little help run on modern Fedora and Ubuntu systems. I just upgraded my
Fedora system from 31 to 34 and they still run. See
<https://gitlab.com/adunstan/pg-old-bin> One of the intended use cases
was to test pg_dump against old versions.

I'm not opposed to us cutting off support for very old versions,
although I think we should only do that very occasionally (no more than
once every five years, say) unless there's a very good reason. I'm also
not opposed to us making small adjustments to allow us to build old
versions on modern platforms, but if we do that then we should probably
have some buildfarm support for it.

cheers

andrew

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-10-25 12:55:37 Re: pg_dump versus ancient server versions
Previous Message Bharath Rupireddy 2021-10-25 12:27:27 Re: Improve the HINT message of the ALTER command for postgres_fdw