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.
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 по дате отправления: