From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
cc: Bruce Momjian <bruce@momjian.us>,
        "Drouvot,
    Bertrand" <bdrouvot@amazon.com>,
        Andres Freund <andres@anarazel.de>,
        Justin Pryzby <pryzby@telsasoft.com>, Noah Misch <noah@leadboat.com>,
        Jason Harvey <jason@reddit.com>, Peter Geoghegan <pg@bowt.ie>,
        PostgreSQL Hackers <pgsql-hackers@postgresql.org>,
        "Tharakan,
    Robins" <tharar@amazon.com>
Subject: Re: [UNVERIFIED SENDER] pg_upgrade can result in early wraparound on databases with high transaction load
In-reply-to: <ECFFD994-D2A9-4E74-A607-01AF4C252340@yesql.se>
References: <CALSof1GM6i21BLr8PsFiRYazakojvesdc+_MiR-L_V5NNkRuWg@mail.gmail.com> <CAH2-Wz=9Cj8H0=GAiHducPETWf6ZXEzjk_pFkjPWnWH6hptpLA@mail.gmail.com> <20190615183759.GB239428@rfd.leadboat.com> <20210423234256.hwopuftipdmp3okf@alap3.anarazel.de> <20210424002827.GO7256@telsasoft.com> <20210424010005.fttcfskp3unr4jiu@alap3.anarazel.de> <fe006d56-85f1-5f1e-98e7-05b53dff4f51@amazon.com> <78bf65ea-517a-51ed-947b-9728a6ace513@amazon.com> <20210727023904.GA19774@momjian.us> <1973418.1657040382@sss.pgh.pa.us> <ECFFD994-D2A9-4E74-A607-01AF4C252340@yesql.se>
Comments: In-reply-to Daniel Gustafsson <daniel@yesql.se>
	message dated "Thu, 16 May 2024 08:11:37 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2122063.1715881657.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 16 May 2024 13:47:37 -0400
Message-ID: <2122064.1715881657@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/2122064.1715881657%40sss.pgh.pa.us>
Precedence: bulk

Daniel Gustafsson <daniel@yesql.se> writes:
>> On 5 Jul 2022, at 18:59, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Given the lack of field complaints, it's probably not worth trying
>> to do anything to restore that capability.  But we really ought to
>> update pg_upgrade's code and docs in pre-v15 branches to say that
>> the minimum supported source version is 9.0.

> (reviving an old thread from the TODO)

> Since we never got around to doing this we still refer to 8.4 as a possi=
ble
> upgrade path in v14 and older.

Oh, yeah, that seems to have fallen through a crack.

> The attached takes the conservative approach of raising the minimum supp=
orted
> version to 9.0 while leaving the code to handle 8.4 in place.  While it =
can be
> removed, the risk/reward tradeoff of gutting code in backbranches doesn'=
t seem
> appealing since the code will be unreachable with this check anyways.

Yeah, it's not worth working harder than this.  I do see one typo
in your comment: s/supported then/supported when/.  LGTM otherwise.

			regards, tom lane