From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>
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, 03 Dec 2021 13:30:31 -0500
Message-ID: <2316211.1638556231@sss.pgh.pa.us> (raw)
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>
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 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 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 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.
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
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: tgl@sss.pgh.pa.us, peter.eisentraut@enterprisedb.com, andres@anarazel.de, 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: <2316211.1638556231@sss.pgh.pa.us>
* 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