Horton

Re: [Proposal] Table-level Transparent Data Encryption (TDE) and Key Management Service (KMS)

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Stephen Frost <sfrost@snowman.net>, Joe Conway <mail@joeconway.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Antonin Houska <ah@cybertec.at>, Haribabu Kommi <kommi.haribabu@gmail.com>, "Moon, Insung" <Moon_Insung_i3@lab.ntt.co.jp>, Ibrar Ahmed <ibrar.ahmad@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-07-11T19:47:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Revamp the WAL record format.

On Tue, Jul 9, 2019 at 10:43 AM Bruce Momjian <bruce@momjian.us> wrote:
> FYI, pg_upgrade already preserves the pg_class.oid, which is why I
> recommended it over pg_class.relfilenode:

I think it's strange that pg_upgrade does not preserve the
relfilenode.  I think it would probably make more sense if it did.

Anyway, leaving that aside, you have to be able to read pg_class to
know the OID of a table, and you can't do that in recovery before
reaching consistency. Yet, you still need to be able to modify disk
blocks at that point, to finish recovery. So I can't see how any
system that involves figuring out the nonce from the OID would ever
work.

If we end up with random nonces, we're going to have to store them
someplace - either in some unencrypted portion of the disk blocks
themselves, or in a separate fork, or someplace else. If it's OK for
them to predictable as long as they vary a lot, we could derive them
from DBOID + RELFILENODE + FORK + BLOCK, but not from DBOID + RELOID +
FORK + BLOCK, because of the aforementioned recovery problem.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company