On Mon, Jun 13, 2022 at 3:06 PM Bruce Momjian <br...@momjian.us> wrote: > That is encryption done in a virtual file system independent of > Postgres. So, I guess the answer to your question is that this is not > how EDB Advanced Server does it.
Okay, thanks for clearing that up. The term "block based" does appear in the article I linked to, so you can see why I didn't understand it that way initially. Anyway, I can see how it would be useful to be able to know the offset of a nonce or of a hash digest on any given page, without access to a running server. But why shouldn't that be possible with other designs, including designs closer to what I've outlined? A known fixed offset in the special area already assumes that all pages must have a value in the first place, even though that won't be true for the majority of individual Postgres servers. There is implicit information involved in a design like the one Robert has proposed; your backup tool (or whatever) already has to understand to expect something other than no encryption at all, or no checksum at all. Tools like pg_filedump already rely on implicit information about the special area. I'm not against the idea of picking a handful of checksum/encryption schemes, with the understanding that we'll be committing to those particular schemes indefinitely -- it's not reasonable to expect infinite flexibility here (and so I don't). But why should we accept something that seems to me to be totally inflexible, and doesn't compose with other things? -- Peter Geoghegan
