From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
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 08:48:47 |
Message-ID: | X+hKbzy3SX9lslS4@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2020-12-27 17:44:50 | Re: pgsql: Add pg_alterckey utility to change the cluster key |
Previous Message | Tom Lane | 2020-12-27 07:09:10 | Re: pgsql: Fix bug #16784 in Disk-based Hash Aggregation. |
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2020-12-27 08:50:11 | Re: Parallel Inserts in CREATE TABLE AS |
Previous Message | Julien Rouhaud | 2020-12-27 08:38:57 | Re: pg_stat_statements oddity with track = all |