Re: Temporary file access API

On Mon, 11 Apr 2022 at 10:05, Antonin Houska <ah(at)cybertec(dot)at> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> > On Fri, Apr 8, 2022 at 4:54 AM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> > > Do you think that the use of a system call is a problem itself (e.g. because
> > > the code looks less simple if read/write is used somewhere and fread/fwrite
> > > elsewhere; of course of read/write is mandatory in special cases like WAL,
> > > heap pages, etc.) or is the problem that the system calls are used too
> > > frequently? I suppose only the latter.
> >
> > I'm not really super-interested in reducing the number of system
> > calls. It's not a dumb thing in which to be interested and I know that
> > for example Thomas Munro is very interested in it and has done a bunch
> > of work in that direction just to improve performance. But for me the
> > attraction of this is mostly whether it gets us closer to TDE.
> >
> > And that's why I'm asking these questions about adopting it in
> > different places. I kind of thought that your previous patches needed
> > to encrypt, I don't know, 10 or 20 different kinds of files. So I was
> > surprised to see this patch touching the handling of only 2 kinds of
> > files. If we consolidate the handling of let's say 15 of 20 cases into
> > a single mechanism, we've really moved the needle in the right
> > direction -- but consolidating the handling of 2 of 20 cases, or
> > whatever the real numbers are, isn't very exciting.
>
> 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.)

I was looking at that list of files that contain user data, and
noticed that all relation forks except the main fork were marked as
'does not contain user data'. To me this seems not necessarily true:
AMs do have access to forks for user data storage as well (without any
real issues or breaking the abstraction), and the init-fork is
expected to store user data (specifically in the form of unlogged
sequences). Shouldn't those forks thus also be encrypted-by-default,
or should we provide some other method to ensure that non-main forks
with user data are encrypted?

- Matthias