From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: Andres Freund <andres@anarazel.de>, Andrew Dunstan <andrew@dunslane.net>,
        Bruce Momjian <bruce@momjian.us>, Robert Haas <robertmhaas@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pg_dump versus ancient server versions
In-reply-to: <196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com>
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>
 <196b40be-c571-e77f-3335-920f8a00047f@enterprisedb.com>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Fri, 03 Dec 2021 17:29:41 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2316210.1638556231.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 03 Dec 2021 13:30:31 -0500
Message-ID: <2316211.1638556231@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2316211.1638556231%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> On 02.12.21 23:16, Andres Freund wrote:
>> I realize it's more complicated for users, but a policy based on suppor=
ting a
>> certain number of out-of-support branches calculated from the newest ma=
jor
>> 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 worthwh=
ile 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 don't find this suggestion to be an improvement over Peter's original
formulation, for two reasons:

* I'm not convinced that it saves us any actual work; as you say, the
code doesn't stop working just because we declare it out-of-support.

* There's a real-world use-case underneath here.  If somewhere you've
discovered a decades-old server that you need to upgrade, and current
pg_dump won't dump from it, you would like it to be well-defined
which intermediate pg_dump versions you can use.  So if 10.19 can
dump from that hoary server, it would not be nice if 10.20 can't;
nor if the documentation lies to you about that based on which minor
version you happen to consult.

>> I think we should explicitly limit the number of platforms we care abou=
t for
>> this purpose. I don't think we should even try to keep 8.2 compile on A=
IX 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.

I agree that if you care about doing this sort of test on platform X,
it's up to you to patch for that.  I think Andres' concern is about
the amount of committer bandwidth that might be needed to handle
such patches submitted by non-committers.  However, based on the
experiment I just ran, I think it's not really likely to be a big deal:
there are not that many problems, and most of them just amount to
back-patching something that originally wasn't back-patched.

What's most likely to happen IMO is that committers will just start
back-patching essential portability fixes into out-of-support-but-
still-in-the-buildability-window branches, contemporaneously with
the original fix.  Yeah, that does mean more committer effort,
but only for a very small number of patches.

			regards, tom lane