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
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 |
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 |