Re: [PATCHES] Post-special page storage TDE support - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [PATCHES] Post-special page storage TDE support
Date
Msg-id 20231113202740.7ja4lmwuvyiip6zh@awork3.anarazel.de
Whole thread Raw
In response to Re: [PATCHES] Post-special page storage TDE support  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [PATCHES] Post-special page storage TDE support  (David Christensen <david.christensen@crunchydata.com>)
List pgsql-hackers
Hi,

On 2023-11-08 18:47:56 -0800, Peter Geoghegan wrote:
> On Wed, Nov 8, 2023 at 6:04 AM Stephen Frost <sfrost@snowman.net> wrote:
> > In conversations with folks (my memory specifically is a discussion with
> > Peter G, added to CC, and my apologies to Peter if I'm misremembering)
> > there was a pretty strong push that a page should be able to 'stand
> > alone' and not depend on something else (eg: pg_control, or whatever) to
> > provide info needed be able to interpret the page.  For my part, I don't
> > have a particularly strong feeling on that, but that's what lead to this
> > design.
> 
> The term that I have used in the past is "self-contained". Meaning
> capable of being decoded more or less as-is, without any metadata, by
> tools like pg_filedump.

I'm not finding that very convincing - without cluster wide data, like keys, a
tool like pg_filedump isn't going to be able to do much with encrypted
pages. Given the need to look at some global data, figuring out the offset at
which data starts based on a value in pg_control isn't meaningfully worse than
having the data on each page.

Storing redundant data in each page header, when we've wanted space in the
page header for plenty other things, just doesn't seem a good use of said
space.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: should check collations when creating partitioned index
Next
From: David Christensen
Date:
Subject: Re: [PATCHES] Post-special page storage TDE support