On Mon, Oct 7, 2019 at 5:48 PM Bruce Momjian <bruce@momjian.us> wrote:
On Mon, Oct 7, 2019 at 11:26:24AM -0400, Robert Haas wrote: > On Mon, Oct 7, 2019 at 11:02 AM Bruce Momjian <bruce@momjian.us> wrote: > > For clog, it is not append-only, and bytes are rewritten (from zero to > > non-zero), so there would have to be a new nonce for every clog file > > write to the file system. We can store the nonce in a separate file, > > but the clog contents and nonce would have to be always synchronized or > > the file could not be properly read. Basically every file we want to > > encrypt, needs this kind of study. > > Yeah. It's a big problem/project. > > Another approach to this problem would be to adjust the block format > to leave room for the nonce. If encryption is not in use, then those > bytes would just be zeroed or something. That would make upgrading a > bit tricky, but pg_upgrade could be taught to do the necessary > conversions for SLRUs without too much pain, I think.
Yes, that is exactly the complexity we have deal with, both in terms of code complexity, reliability, and future maintenance. Currently the file format is unchanged, but as we add more encrypted files, we might need to change it. Fortunately, I think heap/index files don't need to change, so pg_upgrade will not require changes.
It does sound very similar to the problem of being able to add checksums to the clog files (and other SLRUs). So if that can get done, it would help both of those cases (if done right).
