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

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

In response to

Responses

Browse pgsql-committers by date

  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.

Browse pgsql-hackers by date

  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