From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Subject: | Re: storing an explicit nonce |
Date: | 2021-05-30 21:34:19 |
Message-ID: | 20210530213419.dwwsxqtmn5wj4ctw@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2021-05-27 17:00:23 -0400, Bruce Momjian wrote:
> If you go in that direction, you should make sure pg_upgrade preserves
> what you use (it does not preserve relfilenode, just pg_class.oid)
Is there a reason for pg_upgrade not to maintain relfilenode, aside from
implementation simplicity (which is a good reason!). The fact that the old and
new clusters have different relfilenodes does make inspecting some things a
bit harder.
It'd be harder to adjust the relfilenode to match between old/new cluster if
pg_upgrade needed to deal with relmapper using relations (i.e. ones where
pg_class.relfilenode isn't used because they need to be accessed to read
pg_class, or because they're shared), but it doesn't need to.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2021-05-30 22:15:21 | Re: Performance degradation of REFRESH MATERIALIZED VIEW |
Previous Message | Andres Freund | 2021-05-30 21:26:16 | Re: postgres_fdw batching vs. (re)creating the tuple slots |