Re: storing an explicit nonce

Greetings,

* Andres Freund (andres(at)anarazel(dot)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