Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
От | Robert Haas |
---|---|
Тема | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) |
Дата | |
Msg-id | CA+TgmoaxTm1eSJrupvy1+9Y0t_1x9dfhmzHZ2x__36o0WYKa_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)
|
Список | pgsql-hackers |
On Tue, Aug 24, 2021 at 2:16 PM Bruce Momjian <bruce@momjian.us> wrote: > One other issue --- the more that pg_upgrade preserves, the more likely > pg_upgrade will break when some internal changes happen in Postgres. > Therefore, if you want pg_upgrade to preserve something, you have to > have a good reason --- even code simplicity might not be a sufficient > reason. While I accept that as a general principle, I don't think it's really applicable in this case. pg_upgrade already knows all about relfilenodes; it has a source file called relfilenode.c. I don't see that a pg_upgrade that preserves relfilenodes is any more or less likely to break in the future than a pg_upgrade that renumbers all the files so that the relation OID and the relfilenode are equal. You've got about the same amount of reliance on the on-disk layout either way. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: