Re: Key management with tests

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Tom Kincaid <tomjohnkincaid(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(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-03-12 03:31:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I have made significant progress on the cluster file encryption feature so
it is time for me to post a new set of patches.

I went backward and forward on this patch. I went backward and created
significant user and developer documentation for this feature. I went
forward and added heap/index file encryption, so it actually does
something useful.

I have broken the patch into 13 parts, attached, which can be reviewed
separately. However, to get a running system, you have to apply all the
patches in order. The GitHub patch link has more details, has a combined
patch link, and is updated regularly:

I have 13 questions about the patch's approach, marked with XXX
comments. I hope to get these 13 patches into committable shape, but
not commit them, and then continue on to WAL and temporary file
encryption, and pg_basebackup changes. My hope is to have this full
feature committed together early in the PG 15 development cycle. This
progress would not be possible without critical work by Masahiko Sawada
and Stephen Frost.

I have used pgbench to test the performance overhead of this feature.
AES128 shows 2.5% overhead, and AES256 shows 3.5% overhead. My testing
was done on this 16-core, 24MB, single SSD server:

My CPU supports AES acceleration. I made these configuration changes:

shared_buffers = 6GB
effective_io_concurrency = 256
effective_cache_size = 12GB
checkpoint_completion_target = 0.9
max_wal_size = 3GB
wal_compression = on

I used a scale factor of 1000 (15GB database), with this invocation:

pgbench --no-vacuum --protocol prepared --client 32 --jobs 16 --time 3600

I prewarmed the server via pg_prewarm and ran pgbench for an hour before
using the results from another one-hour run. TPS was around 6.5k. For
the default shared_buffers size of 128MB, I see 7% overhead.

Bruce Momjian <bruce(at)momjian(dot)us>

The usefulness of a cup is in its emptiness, Bruce Lee

Attachment Content-Type Size
cfe-01-doc_over_master.diff.gz application/gzip 3.6 KB
cfe-02-internaldoc_over_cfe-01-doc.diff.gz application/gzip 4.7 KB
cfe-03-scripts_over_cfe-02-internaldoc.diff.gz application/gzip 3.1 KB
cfe-04-common_over_cfe-03-scripts.diff.gz application/gzip 8.2 KB
cfe-05-crypto_over_cfe-04-common.diff.gz application/gzip 6.5 KB
cfe-06-backend_over_cfe-05-crypto.diff.gz application/gzip 7.0 KB
cfe-07-bin_over_cfe-06-backend.diff.gz application/gzip 9.1 KB
cfe-08-pg_alterckey_over_cfe-07-bin.diff.gz application/gzip 8.2 KB
cfe-09-test_over_cfe-08-pg_alterckey.diff.gz application/gzip 54.6 KB
cfe-10-hint_over_cfe-09-test.diff.gz application/gzip 4.7 KB
cfe-11-persistent_over_cfe-10-hint.diff text/x-diff 7.2 KB
cfe-12-gist_over_cfe-11-persistent.diff text/x-diff 6.6 KB
cfe-13-rel_over_cfe-12-gist.diff.gz application/gzip 8.9 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2021-03-12 03:33:14 Re: [HACKERS] Custom compression methods
Previous Message Justin Pryzby 2021-03-12 03:24:09 Re: [HACKERS] Custom compression methods