Re: pg_upgrade failures with large partition definitions on upgrades from ~13 to 14~ - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_upgrade failures with large partition definitions on upgrades from ~13 to 14~
Date
Msg-id Y+SKAntI1v7lP7Os@paquier.xyz
Whole thread Raw
In response to Re: pg_upgrade failures with large partition definitions on upgrades from ~13 to 14~  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Feb 09, 2023 at 12:33:06AM -0500, Tom Lane wrote:
> It might be worth expending a pre-check on, if only because the
> check could offer some advice about fixing the problem.

Based on the information coming from pg_class, yes, something could be
reported back.  Now things get more hairy if the oversized tuple has a
mix of long ACLs and a long partition bound.

> But it seems like quite a corner case --- what are the odds of
> hitting this?

Low, I guess, as you need a tuple small enough that it fits right into
a page in 13~, but large enough to hit the upper-bound on insert
because of the extra overhead of relpartbound (something like 20B, at
short glance, in my case).  Well, this would not be an issue if there
were more toasting done.  I agree that schemas with such long
definitions point out to deficiencies usually, but the user experience
is bad when once would expect an upgrade with no hiccups, then fails
on this stuff, delaying an upgrade longer because the instance
requires a rollback.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Rework LogicalOutputPluginWriterUpdateProgress (WAS Re: Logical replication timeout ...)
Next
From: Bharath Rupireddy
Date:
Subject: Re: WAL Insertion Lock Improvements