From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com> |
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-12 16:08:36 |
Message-ID: | 20210112160836.GX27507@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Neil Chen (carpenter(dot)nail(dot)cz(at)gmail(dot)com) wrote:
> On Tue, Jan 12, 2021 at 10:47 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > This is an interesting question but ultimately I don't think we should
> > be looking at this from the perspective of allowing arbitrary changes to
> > the page format. The challenge is that much of the page format, today,
> > is defined by a C struct and changing the way that works would require a
> > great deal of code to be modified and turn this into a massive effort,
> > assuming we wish to have the same compiled binary able to work with both
> > unencrypted and encrypted clusters, which I do believe is a requirement.
> >
> > The thought that I had was to, instead, try to figure out if we could
> > fudge some space by, say, putting a 128-bit 'hole' at the end of the
> > page and just move pd_special back, effectively making the page seem
> > 'smaller' to all of the code that uses it, except for the code that
> > knows how to do the decryption. I ran into some trouble with that but
> > haven't quite sorted out what happened yet. Other ideas would be to put
> > it before pd_special, or maybe somewhere else, but a lot depends on the
> > code's expectations.
>
> I agree that we should not make too many changes to affect the use of
> unencrypted clusters. But as a personal opinion only, I don't think it's a
> good idea to add some "implicit" tricks. To provide an inspiration, can we
> add a flag to mark whether the page format has been changed:
Sure, of course we could add such a flag, but I don't see how that would
actually help with the issue?
> In this way, I think it has little effect on the unencrypted cluster, and
> we can also modify the page format as we wish. Of course, it's also
> possible that I didn't understand your design correctly, or there's
> something wrong with my idea. :D
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.
Thanks,
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-01-12 16:19:44 | Re: Yet another fast GiST build |
Previous Message | Konstantin Knizhnik | 2021-01-12 15:47:36 | Re: libpq compression |