On Tue, Jul 9, 2019 at 10:43 AM Bruce Momjian <br...@momjian.us> wrote: > FYI, pg_upgrade already preserves the pg_class.oid, which is why I > recommended it over pg_class.relfilenode:
I think it's strange that pg_upgrade does not preserve the relfilenode. I think it would probably make more sense if it did. Anyway, leaving that aside, you have to be able to read pg_class to know the OID of a table, and you can't do that in recovery before reaching consistency. Yet, you still need to be able to modify disk blocks at that point, to finish recovery. So I can't see how any system that involves figuring out the nonce from the OID would ever work. If we end up with random nonces, we're going to have to store them someplace - either in some unencrypted portion of the disk blocks themselves, or in a separate fork, or someplace else. If it's OK for them to predictable as long as they vary a lot, we could derive them from DBOID + RELFILENODE + FORK + BLOCK, but not from DBOID + RELOID + FORK + BLOCK, because of the aforementioned recovery problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company