Re: storing an explicit nonce

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: storing an explicit nonce
Дата
Msg-id 20210527160003.GF5646@momjian.us
обсуждение исходный текст
Ответ на Re: storing an explicit nonce  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: storing an explicit nonce  (Andres Freund <andres@anarazel.de>)
Список 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@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

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




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: storing an explicit nonce
Следующее
От: Andres Freund
Дата:
Сообщение: Re: storing an explicit nonce