From: Antonin Houska <ah@cybertec.at>
To: Robert Haas <robertmhaas@gmail.com>
cc: Stephen Frost <sfrost@snowman.net>,
    PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Temporary file access API
In-reply-to: 
 <CA+TgmobQM4Yym3944tFpcaJX4EfYs92Vv4NCY3V0R5BE4RU2rg@mail.gmail.com>
References: <4987.1644323098@antos>
 <20220301143431.GT10577@tamriel.snowman.net> <27013.1646738099@antos>
 <CA+TgmobnojZw6mZi0T_61RtUDgsxroYhp+DJU5Yhz6caxUrQgw@mail.gmail.com>
 <3146.1649408068@antos>
 <CA+TgmobQM4Yym3944tFpcaJX4EfYs92Vv4NCY3V0R5BE4RU2rg@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
   message dated "Fri, 08 Apr 2022 12:01:22 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2131.1649664364.1@antos>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 11 Apr 2022 10:06:04 +0200
Message-ID: <2132.1649664364@antos>
Archived-At: <https://www.postgresql.org/message-id/2132.1649664364%40antos>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> wrote:

> On Fri, Apr 8, 2022 at 4:54 AM Antonin Houska <ah@cybertec.at> wrote:
> > Do you think that the use of a system call is a problem itself (e.g. b=
ecause
> > the code looks less simple if read/write is used somewhere and fread/f=
write
> > 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 to=
o
> > 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_f=
iles_that_contain_user_data

(And pg_stat/* files should be removed from the list.)

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com