Re: Pro et contra of preserving pg_proc oids during pg_upgrade

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Дата
Msg-id CAKFQuwYV3kcCdfgBW5oCzLrmCuNGnuZSVOu2PgQQwHfLqR4Z7Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Pro et contra of preserving pg_proc oids during pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения
On Thu, Oct 12, 2023 at 7:36 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Nikita Malakhov <hukutoc@gmail.com> writes:
> Please advise on the idea of preserving pg_proc oids during pg_upgrade, in
> a way like relfilenodes, type id and so on. What are possible downsides of
> such a solution?

You have the burden of proof backwards.  That would add a great deal
of new mechanism, and you haven't provided even one reason why it'd
be worth doing.


I was curious about the comment regarding type oids being copied over and I found the commentary in pg_upgrade.c that describes which oids are copied over and why, but the IMPLEMENTATION seems to be out-of-sync with the actual implementation.

"""
It preserves the relfilenode numbers so TOAST and other references
to relfilenodes in user data is preserved.  (See binary-upgrade usage
in pg_dump). We choose to preserve tablespace and database OIDs as well.
"""

David J.

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Special-case executor expression steps for common combinations
Следующее
От: Robert Haas
Дата:
Сообщение: Re: New WAL record to detect the checkpoint redo location