pg.ddx.io  pgsql-general@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Dunstan <andrew@dunslane.net>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Drouvot, Bertrand <bdrouvot@amazon.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Justin Pryzby <pryzby@telsasoft.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Jason Harvey <jason@reddit.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: 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
Date: Tue, 05 Jul 2022 18:05:07 -0400
Message-ID: <2021227.1657058707@sss.pgh.pa.us> (raw)
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>

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





view thread (20+ messages)  latest in thread

Message-ID: <2021227.1657058707@sss.pgh.pa.us>
Permalink:  ../2021227.1657058707@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/2021227.1657058707@sss.pgh.pa.us

 · 

reply
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-general@postgresql.org
  Cc: tgl@sss.pgh.pa.us, andrew@dunslane.net, bruce@momjian.us, bdrouvot@amazon.com, andres@anarazel.de, pryzby@telsasoft.com, noah@leadboat.com, jason@reddit.com, pg@bowt.ie, tharar@amazon.com
  Subject: Re: [UNVERIFIED SENDER] Re: pg_upgrade can result in early wraparound on databases with high transaction load
  In-Reply-To: <2021227.1657058707@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