On Fri, Aug 19, 2016 at 07:22:02PM -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.de> writes:
> > On 2016-08-19 17:55:25 -0400, Tom Lane wrote:
> >> It'd be useful also to figure out why our existing valgrind testing has
> >> not caught this already. The example you give looks like it surely
> >> ought to be replicated well enough in the standard regression tests.
>
> > The valgrind suppression file explicitly hides a bunch of padding
> > issues.
>
> So maybe we ought to work towards taking those out?
Maybe. It's a policy question boiling down to our willingness to spend cycles
zeroing memory in order to limit trust in the confidentiality of storage
backing the data directory. Think of "INSERT INTO t VALUES(my_encrypt('key',
'cleartext'))", subsequent to which bits of the key or cleartext leak to disk
by way of WAL padding bytes. A reasonable person might expect that not to
happen; GNU Privacy Guard and a few like-minded programs prevent it. I'm on
the fence regarding whether PostgreSQL should target this level of vigilance.
An RDBMS is mainly a tool for managing persistent data, and PostgreSQL will
never be a superior tool for data that _must not_ persist. Having said that,
the runtime cost of zeroing memory and the development cost of reviewing the
patches to do so is fairly low.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
