Re: storing an explicit nonce

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: storing an explicit nonce
Дата
Msg-id 20210531201652.GY20766@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: storing an explicit nonce  (Andres Freund <andres@anarazel.de>)
Ответы Re: storing an explicit nonce  (Robert Haas <robertmhaas@gmail.com>)
Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> 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.

This was discussed for a bit during the Unconference (though it was
related to backups and major upgrades which involves replicas) and the
general consensus seemed to be that, no, it wasn't for any specific
reason beyond that pg_upgrade didn't need to preserve relfilenode and
therefore didn't.

There was a discussion around if there were possibly any pitfalls that
we might run into, should we try to have pg_upgrade preserve
relfilenodes but I don't *think* there were any actual show stoppers
that came up.  The simplest approach, I would think, would be to have it
do the same thing that it does for OIDs today- basically have pg_dump in
binary mode emit a function call to inform the backend of what
relfilenode to use for the next CREATE statement.  We would need to also
pass into that function if the table should have a TOAST table and what
the relfilenode for that should be too, for the base table.  We'd need
to also handle indexes, mat views, etc, of course.

> 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.

Right, and we generally shouldn't need to worry about conflicts arising
from relfilenodes used by catalog tables since the new cluster should be
a freshly initdb'd cluster and everything in the fresh catalog should be
below the relfilenode values we use for user relations.

There did seem to generally be some usefulness to having relfilenodes
preserved across major version upgrades beyond TDE and that's a pretty
independent project that could be tackled independently of TDE efforts.

Thanks,

Stephen

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: make world and install-world without docs
Следующее
От: Tom Lane
Дата:
Сообщение: Re: CALL versus procedures with output-only arguments