Re: pg_upgrade failures with large partition definitions on upgrades from ~13 to 14~

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> The following SQL sequence causes a failure of pg_upgrade when these
> are executed on a cluster of ~13, doing an upgrade to 14~, assuming
> that the relation page size is 8kB.
> ...
> No fields have been added to pg_class between 13 and 14, however the
> amount of data stored in relpartbound got larger between these two
> versions (just do a length() on it for example using what I posted
> above). Hence, if the original cluster has a version of pg_class
> large enough to just fit into a single page without the need of
> toasting, it may fail when created in the new cluster because it lacks
> space to fit on a page because of this extra partition bound data.

Bleah.

> Shouldn't we have a safeguard of some kind in the pre-check phase of
> pg_upgrade at least? I think that this comes down to checking
> sum(pg_column_size(pg_class.*)), roughly, with alignment and page
> header, and do the same for pg_attribute.

It might be worth expending a pre-check on, if only because the
check could offer some advice about fixing the problem. But it
seems like quite a corner case --- what are the odds of hitting
this?

regards, tom lane