From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Nikita Malakhov <hukutoc(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Pro et contra of preserving pg_proc oids during pg_upgrade |
Date: | 2023-10-12 18:00:39 |
Message-ID: | CAKFQuwYV3kcCdfgBW5oCzLrmCuNGnuZSVOu2PgQQwHfLqR4Z7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 12, 2023 at 7:36 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Nikita Malakhov <hukutoc(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-10-12 18:10:31 | Re: New WAL record to detect the checkpoint redo location |
Previous Message | Andres Freund | 2023-10-12 17:52:04 | Re: Special-case executor expression steps for common combinations |