Hello! I am glad to see that there are multiple TDE extension proposals being worked on. For context, I am one of the developers working on the pg_tde[1] extension, as well as on the extensible SMGR proposal that Konstantin already linked.
This patch/proposal contains two distinct parts of encryption/extensibility, WAL and buffer manager/table data. Based on earlier discussions, the opinions of adding extension points to these two are quite different, and because of that I'm not sure if bundling them together is helpful. It also appears to be missing some extension points that would be required for a more complete encryption solution, such as encrypting temporary files or system tables, or handling command-line utilities like pg_waldump. Do you have ideas or patches in mind for those areas as well? I have the same question as Konstantin, why did you choose custom hooks for the buffer manager instead of the already existing smgr interface / extensibility patch? While that patch is not part of the core (but I hope it will be), it is already used by multiple companies as it supports other use cases, not only encryption. We plan to focus more on that thread early next year, we would appreciate any feedback/suggestions that could make it better for others. I also noticed that you added additional flags to the page header. Initially we were thinking about something like this, but decided that the fork files are better for any encryption (or other storage related) extra data. These few bits try to be generic, while also restrictive because of the limited amount of data. (and that data is specifically per page, if I want something per file or per page range, I still need a custom solution) Regarding the WAL encryption part, we took a completely different approach, similar to how we handle normal table data (page-based). I will need to think more about this before I can provide meaningful feedback on that part of the patch. One initial question, however, is whether you have run detailed benchmarks with different workloads. That seems to be the trickiest part there, since most of the code runs in a critical section. (Not the "unused"/"empty hook" path, but the overhead caused by a real encryption plugin using this hook in practice) [1]: https://github.com/percona/pg_tde
