|From:||Bruce Momjian <bruce(at)momjian(dot)us>|
|To:||Robert Haas <robertmhaas(at)gmail(dot)com>|
|Cc:||Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>|
|Subject:||Re: storing an explicit nonce|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On Wed, May 26, 2021 at 01:56:38PM -0400, Robert Haas wrote:
> In the interest of not being viewed as too much of a naysayer, let me
> first reiterate that I am generally in favor of TDE going forward and
> am not looking to throw up unnecessary obstacles in the way of making
> that happen.
Rather than surprise anyone, I might as well just come out and say some
things. First, I have always admitted this feature has limited
I think a non-LSN nonce adds a lot of code complexity, which adds a code
and maintenance burden. It also prevents the creation of an encrypted
replica from a non-encrypted primary using binary replication, which
makes deployment harder.
Take a feature of limited usefulness, add code complexity and deployment
difficulty, and the feature becomes even less useful.
For these reasons, if we decide to go in the direction of using a
non-LSN nonce, I no longer plan to continue working on this feature. I
would rather work on things that have a more positive impact. Maybe a
non-LSN nonce is a better long-term plan, but there are too many
unknowns and complexity for me to feel comfortable with it.
If only the physical world exists, free will is an illusion.
|Next Message||Tom Lane||2021-05-26 21:19:52||Re: Add PortalDrop in exec_execute_message|
|Previous Message||Alvaro Herrera||2021-05-26 20:59:17||Re: Add PortalDrop in exec_execute_message|