Re: pg_dump versus ancient server versions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump versus ancient server versions
Date
Msg-id 4049941.1635181783@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump versus ancient server versions  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_dump versus ancient server versions  (Andres Freund <andres@anarazel.de>)
Re: pg_dump versus ancient server versions  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2021-10-22 19:30:25 -0400, Tom Lane wrote:
>> 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.

> I'd really like us to adopt a "default" policy on this. I think it's a waste
> to spend time every few years arguing what exact versions to drop. I'd much
> rather say that, unless there are concrete reasons to deviate from that, we
> provide pg_dump compatibility for 5+3 releases, pg_upgrade for 5+1, and psql
> for 5 releases or something like that.

I agree with considering something like that to be the minimum support
policy, but the actual changes need a bit more care.  For example, when
we last did this, the technical need was just to drop pre-7.4 versions,
but we chose to make the cutoff 8.0 on the grounds that that was more
understandable to users [1].  In the same way, I'm thinking of moving the
cutoff to 9.0 now, although 8.4 would be sufficient from a technical
standpoint.

OTOH, in the new world of one-part major versions, it's less clear that
there will be obvious division points for future cutoff changes.  Maybe
versions-divisible-by-five would work?  Or versions divisible by ten,
but experience so far suggests that we'll want to move the cutoff more
often than once every ten years.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/2661.1475849167%40sss.pgh.pa.us



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_dump versus ancient server versions
Next
From: Robert Haas
Date:
Subject: Re: pgsql: Remove unused wait events.