Date: Sat, 1 Nov 2025 09:58:24 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Kai Wagner <kai.wagner@percona.com>
Cc: Chris Travers <chris.travers@gmail.com>,
	Christophe Pettus <xof@thebuild.com>,
	"Clay Jackson (cjackson)" <Clay.Jackson@quest.com>,
	pgsql-general <pgsql-general@postgresql.org>,
	Laurenz Albe <laurenz.albe@cybertec.at>,
	Ron Johnson <ronljohnsonjr@gmail.com>
Subject: Re: Enquiry about TDE with PgSQL
Message-ID: <aQYSAGEfd116_58N@momjian.us>
References: <a1dae4a583d560a90c67872b766ead02ddb13e51.camel@cybertec.at>
 <aQPDvqUzZVKkaxsS@momjian.us>
 <CAG0qCNhL=SEB4vc4v48PxN1F-t8htC463TpX7KDNWQ-s3s8dtA@mail.gmail.com>
 <aQTNmM-3VeTRZdx0@momjian.us>
 <FC8C7F2D-CD38-42C7-80D3-516239B70A2D@thebuild.com>
 <aQVScCjItvCtgVPn@momjian.us>
 <CO1PR19MB4984B665A5F9F38A5E0FB5969BF9A@CO1PR19MB4984.namprd19.prod.outlook.com>
 <3DC589BC-A5F6-49BC-BFFC-F1FCB0FF7E95@thebuild.com>
 <CAKt_ZfuwPgG_nJHp6S=8k_+NdA6Op7hE0z7+s4-HuBqr1cnwsg@mail.gmail.com>
 <CAG0qCNjd2m9Ej1ZEwuCCkgsqJz0vnso3ZFwjKCxzwUfnfu=SNw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAG0qCNjd2m9Ej1ZEwuCCkgsqJz0vnso3ZFwjKCxzwUfnfu=SNw@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aQYSAGEfd116_58N%40momjian.us>
Precedence: bulk

On Sat, Nov  1, 2025 at 08:34:57AM +0100, Kai Wagner wrote:
> I wholeheartedly agree, as in this thread we are trying to do the same thing
> again, that has already happened all they years before. We lose ourselves in
> technical reasons, wondering why this makes no sense and how it could be
> achieved differently, but we forget that we live in a vacuum and bubble here. 
> The auditor, most of the time (as I've seen many times), has no knowledge of
> these technical aspects. It's a box to check, with a simple 'yes' or 'no'. They
> don't even wanna hear any "but this also satisfies it, as this isn't clearly
> stated and worded in the standard". This doesn't get us anywhere anymore; they
> will not put their checkbox there if there is no simple answer to it.
> 
> @Bruce Momjian I totally understand your frustration from previous times and
> also your point of view, that's absolutely valid, no doubt about that. The time
> has changed over the course of the last 5+ years, and maybe it is time to
> reconsider. Just because it didn't succeed last time doesn't mean we have to
> end up in the same spot this time. We discussed it at length, and I am
> committed to supporting and making happen what's necessary to get TDE fully
> functional with postgres directly. The way of the implementation is a different
> question. Who from the former times, or maybe even now, being interested in the
> topic, would be open for a TDE group, to technically discuss options,
> possibilities etc. that we can POC on and share for further feedback?!

Without the calculus of feature value vs code overhead changing, talking
isn't going to accomplish anything.  My patch was already very small for
shared buffers, and the WAL code would have been small, but the code
weight of encrypting temporary files wasn't justified by the community,
and I couldn't argue against that conclusion.

Crunchy had someone working on restructuring temporary file writes to
make it easier, but they were unsuccessful.  Maybe the posted temporary
file compression patch will help reduce the code weight.

If you want to move forward with TDE without waiting to see if the
temporary file compression patch will reduce the TDE code impact, you
need to dig into how the community does feature calculus and how that
calculus can be changed --- this is not something technology can fix.

Companies are willing to add the code weight because it is a sale for
them, and customers are willing to pay to meet the check box --- that
calculus just doesn't work in the community.

-- 
  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.