Re: storing an explicit nonce
Bruce Momjian <bruce@momjian.us>
From: Bruce Momjian <bruce@momjian.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>, Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Masahiko Sawada <sawada.mshk@gmail.com>, Tom Kincaid <tomjohnkincaid@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Date: 2021-05-27T16:00:03Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Rethink method for assigning OIDs to the template0 and postgres DBs.
- 2cb1272445d2 15.0 landed
-
pg_upgrade: Preserve database OIDs.
- aa01051418f1 15.0 landed
-
pg_upgrade: Preserve relfilenodes and tablespace OIDs.
- 9a974cbcba00 15.0 landed
-
Fix for new Boolean node
- cf925936ecc0 15.0 cited
-
Improve error handling of HMAC computations
- 5513dc6a304d 15.0 cited
-
Add macro RelationIsPermanent() to report relation permanence
- 95d77149c535 14.0 landed
-
Enhance nbtree index tuple deletion.
- d168b666823b 14.0 cited
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.