| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 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-26 19:00:02 |
| Message-ID: | 20201226190002.GP19054@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
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.
I have an idea. I can add debug code that outputs key 0 as hex to the
file descriptor open to the terminal, and compare the initdb value to
the server-start value. The existing code doesn't do anything useful,
so having debug output until it does seems acceptable, if it is enabled.
--
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 | Michael Paquier | 2020-12-27 01:11:17 | Re: pgsql: Add pg_alterckey utility to change the cluster key |
| Previous Message | Bruce Momjian | 2020-12-26 17:18:18 | Re: pgsql: Add pg_alterckey utility to change the cluster key |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zhihong Yu | 2020-12-26 19:12:02 | Re: SQL/JSON: functions |
| Previous Message | Tom Lane | 2020-12-26 18:37:15 | Re: Better client reporting for "immediate stop" shutdowns |