Thanks Christophe for the clarification.
That's not quite right. A PostgreSQL cluster (in the traditional sense,
> which means one PostgreSQL server handling a particular endpoint) is
> isolated from any other clusters on the same machine.
>
Thanks. I think I had a misunderstanding over the "clu
Thanks all for the discussions. It sounds like there are different
questions to clear before we can get to a conclusion on if per-database KEK
is possible or not.
First question - do we, as a community, see the value of the proposal and
do we believe that value is big enough for us to make any nec
sters then?
Better isolation of the customers, but still on one server.
On Thu, May 18, 2023 at 3:53 PM Stephen Frost wrote:
> Greetings,
>
> Please don't top-post on these lists.
>
> * Tony Xu (tony...@rubrik.com) wrote:
> > Our use-case is for a multi-tenancy
r, it also makes sense to allow them
to have completely independent encryption facilities?
Thanks,
Tony
On Thu, May 18, 2023 at 8:54 AM Stephen Frost wrote:
> Greetings,
>
> * Tony Xu (tony...@rubrik.com) wrote:
> > The FAQ (copied below) mentioned that native transparent data
Ok, thanks for the clarification. Any particular reason for the change of
plans? Would it come in 17?
Thanks
Tony
On Wed, May 17, 2023, 5:49 PM Bruce Momjian wrote:
> On Wed, May 17, 2023 at 03:35:39PM -0700, Tony Xu wrote:
> > Hi There,
> >
> > The FAQ (copied below)
Hi There,
The FAQ (copied below) mentioned that native transparent data encryption
might be included in 16. Is it fair to assume that it will support database
level encryption, that is, we can use two encryption keys for two databases
in the same server, respectively? How can one verify that?
Tha
