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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers