Re: pgsql: Add pg_alterckey utility to change the cluster key

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Add pg_alterckey utility to change the cluster key
Date: 2020-12-27 17:44:50
Message-ID: 20201227174450.GC17037@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sun, Dec 27, 2020 at 05:48:47PM +0900, Michael Paquier wrote:
> On Sat, Dec 26, 2020 at 02:00:02PM -0500, Bruce Momjian wrote:
> > On Sat, Dec 26, 2020 at 12:18:18PM -0500, Bruce Momjian wrote:
> >> I can easily revert and come back, though the buildfarm is green now.
> >> As far as testing, I can test that the cluster key unlocks the data
> >> keys, but there is no current interface to the data keys. Ideally we
> >> would test the full input/output path, but with no access to the output,
> >> how can we test it? Also, as I stated, there are some shell script APIs
> >> that can't easily be tested, e.g. AWS, Yubikey. I can continue to test
> >> those manually.
>
> It seems to me that it is better to figure out that while the feature
> is being developed, not after committing it so as there are
> fully-functional tests at the same time the feature is committed. If
> we don't have that in place, how can people know the amount of testing
> that has been done for this feature? And how can anybody be sure that
> nothing breaks if this area of the code gets changed? Manual testing
> does not scale. For example, I have seen cases in the past where
> implementing tests improved the whole state of a feature design
> because it was possible to finish with a more flexible set of methods
> for this feature.
>
> Based on the number of concerns raised by various people over the last
> couple of days (including myself, one point being the refactoring of
> the ciphers taken from pgcrypto that should have been in its own
> commit), I agree that it would be better to revert this code for now.

OK, I will do so in the next few hours. My followup will be to:

* register it for the commit-fest so it gets cfbot and other visibility
* modify pgcrypto to use the new AES API (the SHA512 call no longer exists)
* develop TAP tests, though as I mentioned, they will be odd

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

The usefulness of a cup is in its emptiness, Bruce Lee

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Jeff Davis 2020-12-27 17:53:01 pgsql: Stabilize test introduced in 05c02589, per buildfarm.
Previous Message Michael Paquier 2020-12-27 08:48:47 Re: pgsql: Add pg_alterckey utility to change the cluster key

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2020-12-27 17:53:13 Re: range_agg
Previous Message Justin Pryzby 2020-12-27 17:39:43 Re: Add table access method as an option to pgbench