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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_upgrade failures with large partition definitions on upgrades from ~13 to 14~
Дата
Msg-id Y+SKAntI1v7lP7Os@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_upgrade failures with large partition definitions on upgrades from ~13 to 14~  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Rework LogicalOutputPluginWriterUpdateProgress (WAS Re: Logical replication timeout ...)
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: WAL Insertion Lock Improvements