Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Apr 11, 2022 at 4:05 AM Antonin Houska <a...@cybertec.at> wrote: > > There are't really that many kinds of files to encrypt: > > > > https://wiki.postgresql.org/wiki/Transparent_Data_Encryption#List_of_the_files_that_contain_user_data > > > > (And pg_stat/* files should be removed from the list.) > > This kind of gets into some theoretical questions. Like, do we think > that it's an information leak if people can look at how many > transactions are committing and aborting in pg_xact_status? In theory > it could be, but I know it's been argued that that's too much of a > side channel. I'm not sure I believe that, but it's arguable.
I was referring to the fact that the statistics are no longer stored in files: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd > Similarly, the argument that global/pg_internal.init doesn't contain > user data relies on the theory that the only table data that will make > its way into the file is for system catalogs. I guess that's not user > data *exactly* but ... are we sure that's how we want to roll here? Yes, this is worth attention. > I really don't know how you can argue that pg_dynshmem/mmap.NNNNNNN > doesn't contain user data - surely it can. Good point. Since postgres does not control writing into this file, it's a special case though. (Maybe TDE will have to reject to start if dynamic_shared_memory_type is set to mmap and the instance is encrypted.) Thanks. -- Antonin Houska Web: https://www.cybertec-postgresql.com
