From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
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>,
        pgsql-hackers@postgresql.org, "Tharakan, Robins" <tharar@amazon.com>
Subject: Re: [UNVERIFIED SENDER] Re: pg_upgrade can result in early wraparound
 on databases with high transaction load
In-reply-to: <67a252e2-c847-f1f0-106e-ea4f7ffc543a@dunslane.net>
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>
 <220cb128-4f52-237b-66d8-8dbcd75ead53@dunslane.net>
 <1997756.1657048658@sss.pgh.pa.us>
 <67a252e2-c847-f1f0-106e-ea4f7ffc543a@dunslane.net>
Comments: In-reply-to Andrew Dunstan <andrew@dunslane.net>
	message dated "Tue, 05 Jul 2022 17:25:43 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <2021226.1657058707.1@sss.pgh.pa.us>
Content-Transfer-Encoding: 8bit
Date: Tue, 05 Jul 2022 18:05:07 -0400
Message-ID: <2021227.1657058707@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2021227.1657058707%40sss.pgh.pa.us>
Precedence: bulk

Andrew Dunstan <andrew@dunslane.net> writes:
> On 2022-07-05 Tu 15:17, Tom Lane wrote:
>> Hmm ... could you first look into why 09878cdd4 broke it?  I'd supposed
>> that that was just detecting situations we must already have dealt with
>> in order for the pg_upgrade test to work, but crake's not happy.

> It's complaining about this:

> andrew@emma:HEAD $ cat
> ./inst/REL9_6_STABLE-20220705T160820.039/incompatible_polymorphics.txt
> In database: regression
>   aggregate: public.first_el_agg_f8(double precision)

Thanks.

> I can have TestUpgradeXVersion.pm search for and remove offending
> functions, if that's the right fix.

I'm not sure.  It seems like the new check must be too strict,
because it was only meant to detect cases that would cause a subsequent
dump/reload failure, and evidently this did not.  I'll have to look
closer to figure out what to do.  Anyway, it's off topic for this
thread ...

			regards, tom lane