Re: storing an explicit nonce

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
Date: 2021-05-27 16:00:03
Message-ID: 20210527160003.GF5646@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 26, 2021 at 05:02:01PM -0400, Bruce Momjian wrote:
> Rather than surprise anyone, I might as well just come out and say some
> things. First, I have always admitted this feature has limited
> usefulness.
>
> 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.

I had some more time to think about this. The big struggle for this
feature has not been writing it, but rather keeping it lean enough that
its code complexity will be acceptable for a feature of limited
usefulness. (The Windows port and pg_upgrade took similar approaches.)

Thinking about the feature to add checksums online, it seems to have
failed due to us over-complexifying the feature. If we had avoided
allowing the checksum restart requirement, the patch would probably be
part of Postgres today. However, a few people asked for
restart-ability, and since we don't really have much infrastructure to
do online whole-cluster changes, it added a lot of code. Once the patch
was done, we looked at the code size and the benefits of the feature,
and decided it wasn't worth it.

I suspect that if we start adding a non-LSN nonce and malicious write
detection, we will end up with the same problem --- a complex patch for
a feature that has limited usefulness, and requires dump/restore or
logical replication to add it to a cluster. I think such a patch would
be rejected, and I would probably even vote against it myself.

I don't want this to sound like I only want to do this my way, but I
also don't want to be silent when I smell failure, and if the
probability of failure gets too high, I am willing to abandon a feature
rather than continue.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2021-05-27 16:01:05 Re: storing an explicit nonce
Previous Message Stephen Frost 2021-05-27 15:49:33 Re: storing an explicit nonce