Re: Temporary file access API

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Temporary file access API
Дата
Msg-id CA+TgmobnojZw6mZi0T_61RtUDgsxroYhp+DJU5Yhz6caxUrQgw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Temporary file access API  (Antonin Houska <ah@cybertec.at>)
Ответы Re: Temporary file access API  (Antonin Houska <ah@cybertec.at>)
Список pgsql-hackers
On Tue, Mar 8, 2022 at 6:12 AM Antonin Houska <ah@cybertec.at> wrote:
> Thanks for your comments, the initial version is attached here.

I've been meaning to look at this thread for some time but have not
found enough time to do that until just now. And now I have
questions...

1. Supposing we accepted this, how widely do you think that we could
adopt it? I see that this patch set adapts a few places to use it and
that's nice, but I have a feeling there's a lot more places that are
making use of system calls directly, or through some other
abstraction, than just this. I'm not sure that we actually want to use
something like this everywhere, but what would be the rule for
deciding where to use it and where not to use
it? If the plan for this facility is just to adapt these two
particular places to use it, that doesn't feel like enough to be
worthwhile.

2. What about frontend code? Most frontend code won't examine data
files directly, but at least pg_controldata, pg_checksums, and
pg_resetwal are exceptions.

3. How would we extend this to support encryption? Add an extra
argument to BufFileStreamInit(V)FD passing down the encryption
details?

There are some smaller things about the patch with which I'm not 100%
comfortable, but I'd like to start by understanding the big picture.

Thanks,

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: should vacuum's first heap pass be read-only?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas