Re: Enquiry about TDE with PgSQL

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Enquiry about TDE with PgSQL
Дата
Msg-id aQjeuRsBLS6cXNLC@momjian.us
обсуждение исходный текст
Ответ на Re: Enquiry about TDE with PgSQL  (Kai Wagner <kai.wagner@percona.com>)
Ответы Re: Enquiry about TDE with PgSQL
Список pgsql-general
On Sun, Nov  2, 2025 at 11:14:58AM +0100, Kai Wagner wrote:
> I fully agree here, and as I stated above, I don't question this at all, as
> this is the strength of the diverse and spread community. Looking at this
> thread alone, and the multiple different "users" popping up, that see the need
> and would like to see TDE in core or in an extension drives my thinking as it
> makes sense to start thinking and looking into the temp file compression
> already right now, if and how this could make our code changes easier, or if
> additional extensibility should be directly part of the first patch, so you can
> enable it through its extension. Either way, it should be considered and kept
> in mind now, not after the fact, or we will continue to spin this wheel. And
> this thinking and willingness alone, to actually be open to that idea, requires
> some upfront discussion, so you at least know you are welcome to work on it
> without wasting effort, because no one will ever want to merge. (and yes, of
> course everyone can work on whatever they want at any point in time, but people
> might prefer working on something that actually benefits the project and is
> welcome, rather than ending in >/dev/null)
> 
> Given your experience Bruce, can you offer us some advice on how you would
> approach it currently? What do you think makes the most sense, and how should
> we proceed with collaboration to at least see a small change in making this
> happen in the future? 

Good questions.  I think we have to decide if the community wants TDE,
and if so how much code change will the community accept to get it.  And
then we have to decide if this happens in an extension, like Percona's,
or in the core code.

The problem with the Percona extension is it seems like it was developed
mostly/all by Percona employees, meaning development was driven/steered
by Percona, and there was insufficient feedback from the community for
it to be polished enough to be a general community solution.  (I
fortunately attended all the Percona TDE talks at the Riga conference.)
The community needs to get involved with that extension if it is to
become a community-polished solution.

An extension does allow for fewer core code changes, but as I stated in
a previous email, the changes needed for command-line tools, external
tools, and replication to work in a TDE environment could make an
extension-based-TDE API too complex to be useful.

As far as how to move forward, I think we need to look at the temporary
file compression patch, see if that will help TDE code impact, and then
decide, with that patch, if the TDE core code impact is acceptable.  If
not, we then need to look at an extension, what hooks are needed, and
then decide if the final result have a simple enough API to be useful. 
(Do we start from scratch or use Percona's?)  If the API is complex, and
could lead to corruption/data loss due to encryption, that solution is
unacceptable.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.



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