From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
Date: Fri, 3 Dec 2021 17:29:41 +0100
Message-ID: <196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com> (raw)
In-Reply-To: <20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de>
References: <CA+TgmoboH6=SgWHPddv_8ie91Qf2ECKSvg-72aYajKb2gyLYQg@mail.gmail.com>
<202110222351.3f42l5fgo3lw@alvherre.pgsql>
<CA+TgmobB8cj30z6dzEf5xNTxzGRNGmkJsCr3nv_Hneo0o5kozg@mail.gmail.com>
<3783090.1635111977@sss.pgh.pa.us>
<CA+TgmobQxeGVtgxQz_OxdgCO4r=Tb2SaCh9FJ8Dxjaq9DxHH_g@mail.gmail.com>
<3883429.1635171820@sss.pgh.pa.us>
<20211025170657.ekufa7urdcyzpgdm@alap3.anarazel.de>
<c51ede27-3b6d-1d27-9d1a-227526858db2@dunslane.net>
<22018.1635202338@sss.pgh.pa.us>
<d0316012-ece7-7b7e-2d36-9c38cb77cb3b@enterprisedb.com>
<20211202221607.xovsdnoh5tpbnhbs@alap3.anarazel.de>
On 02.12.21 23:16, Andres Freund wrote:
> I think we should at least include pg_upgrade in this as well, it's pretty
> closely tied to at least pg_dump.
right
>> * pg_dump and psql will maintain compatibility with servers at least
>> ten major releases back.
>
> Personally I think that's too long... It boils down keeping branches buildable
> for ~15 years after they've been released. That strikes me as pretty far into
> diminishing-returns, and steeply increasing costs, territory.
Well, it is a lot, but it's on the order of what we have historically
provided.
> I realize it's more complicated for users, but a policy based on supporting a
> certain number of out-of-support branches calculated from the newest major
> version is more realistic. I'd personally go for something like newest-major -
> 7 (i.e. 2 extra releases), but I realize that others think it's worthwhile to
> support a few more. I think there's a considerable advantage of having one
> cutoff date across all branches.
I'm not sure it will be clear what this would actually mean. Assume
PG11 supports back to 9.4 (14-7) now, but when PG15 comes out, we drop
9.4 support. But the PG11 code hasn't changed, and PG9.4 hasn't changed,
so it will most likely still work. Then we have messaging that is out
of sync with reality. I can see the advantage of this approach, but the
communication around it might have to be refined.
> I think we should explicitly limit the number of platforms we care about for
> this purpose. I don't think we should even try to keep 8.2 compile on AIX or
> whatnot.
It's meant to be developer-facing, so only for platforms that developers
use. I think that can police itself, if we define it that way.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@enterprisedb.com, andres@anarazel.de, tgl@sss.pgh.pa.us, andrew@dunslane.net, bruce@momjian.us, robertmhaas@gmail.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Subject: Re: pg_dump versus ancient server versions
In-Reply-To: <196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox