Horton

Re: [UNVERIFIED SENDER] Re: pg_upgrade can result in early wraparound on databases with high transaction load

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
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>
Date: 2022-07-05T22:05:07Z
Lists: pgsql-hackers, pgsql-general 
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

Commits

  1. Refuse upgrades from pre-9.0 clusters

  2. pg_resetxlog: add option to set oldest xid & use by pg_upgrade

  3. Stamp 11.2.

  4. Track the current XID wrap limit (or more accurately, the oldest unfrozen