On Tue, Jun 14, 2022 at 11:52 AM Robert Haas <robertmh...@gmail.com> wrote: > > Even within TDE, it might be okay to assume that it's a feature that > > the user must commit to using for a whole cluster at initdb time. What > > isn't okay is committing to that assumption now and forever, by > > leaving the door open to a world in which that assumption no longer > > holds. Like when you do finally get around to making TDE something > > that can work at the relation level, for example. Even if there is > > only a small chance of that ever happening, why wouldn't we be > > prepared for it, just on general principle? > > To the extent that we can leave ourselves room to do new things in the > future without incurring unreasonable costs in the present, I'm in > favor of that, as I believe anyone would be. But as you say, a lot > depends on the specifics. Theoretical flexibility that can only be > used in practice by really slow code doesn't help anybody.
A tool like pg_filedump or a backup tool can easily afford this overhead. The only cost that TDE has to pay for this added flexibility is that it has to set one of the PD_* bits in a code path that is already bound to be very expensive. What's so bad about that? Honestly, I'm a bit surprised that you're pushing back on this particular point. A nonce for TDE is just something that code in places like bufpage.h ought to know about. It has to be negotiated at that level, because it will in fact affect a lot of callers to the bufpage.h functions. -- Peter Geoghegan
