On 2019-Jul-05, Bruce Momjian wrote: > Uh, well, you have the WAL record, and you want to write it to an 8k > page. You have to read the 8k page from disk into shared buffers, and > you have to decrypt the 8k page to do that, right? We aren't going to > store 8k pages encrypted in shared buffers, right?
Oh, is that the idea? I was kinda assuming that the data was kept as-stored in shared buffers, ie. it would be decrypted on access, not on read from disk. The system seems very prone to leakage if you have it decrypted in shared memory. If you keep it unencrypted in shared_buffers, you'd require WAL replay and checkpointer to have every single key in the system. That sounds nightmarish -- a single user can create a table, hide the key and block WAL replay and checkpointing for the whole system. I haven't read the whole thread, sorry about that -- maybe these points have already been discussed. > Also, that assumes that we are only encrypting the WAL payload, and not > the relation oids or other header information, which I think is a > mistake because it will lead to information leakage. Well, that was part of my question. Why do you care to encrypt metadata such as the relation OID (or really relfilenode)? Yes, I was assuming that only the WAL payload is encrypted. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services