On Thu, Jul 11, 2019 at 03:47:50PM -0400, Robert Haas wrote: > 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.
Later in this thread, we decided that the page LSN was the best option as a nonce because it changes every time the page chages. (We will enable wal_log_hints.) We will not encrypt the first 16 bytes of the page so it can be used for the nonce. (AES block ciphers are use 16-byte blocks.) -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
