From: | Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Subject: | Re: Key management with tests |
Date: | 2021-01-13 02:26:04 |
Message-ID: | CAA3qoJ=UL-7R58bE1AuiHeiRr+5wDtLD5a1F7yuArTqU0sR=Rw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thank you for your reply,
On Wed, Jan 13, 2021 at 12:08 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> No, we can't 'modify the page format as we wish'- if we change away from
> using a C structure then we're going to be modifying quite a bit of
> code which otherwise doesn't need to be changed. The proposed flag
> doesn't actually make a different page format work, the only thing it
> would do would be to allow some parts of the cluster to be encrypted and
> other parts not be, but I don't know that that's actually a useful
> capability or a good reason to use one of those bits. Having it handled
> on a cluster level, at initdb time through pg_control, seems like it'd
> work just fine.
>
>
Yes, I realized that for cluster-level encryption, it would be unwise to
flag a single page(Unless we want to do it at relation-level). Forgive me
for not describing clearly, the 'modify the page' I said means the method
you mentioned, not modifying the C structure. My original motivation is to
avoid storing in an unconventional format without a description of the C
structure. However, as I just said, it seems that we should not set
the flag for a single page. Maybe it's enough to just add a comment
description?
From | Date | Subject | |
---|---|---|---|
Next Message | Edmund Horner | 2021-01-13 02:37:50 | Re: Tid scan improvements |
Previous Message | Michael Paquier | 2021-01-13 02:25:02 | Re: Moving other hex functions to /common |