Re: Pro et contra of preserving pg_proc oids during pg_upgrade - Mailing list pgsql-hackers

From David G. Johnston
Subject Re: Pro et contra of preserving pg_proc oids during pg_upgrade
Date
Msg-id CAKFQuwYV3kcCdfgBW5oCzLrmCuNGnuZSVOu2PgQQwHfLqR4Z7Q@mail.gmail.com
Whole thread Raw
In response to Re: Pro et contra of preserving pg_proc oids during pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: Special-case executor expression steps for common combinations
Next
From: Robert Haas
Date:
Subject: Re: New WAL record to detect the checkpoint redo location