On 11/19/15 1:12 PM, Adrian Klaver wrote:
>Our app is doing the authentication based on the sensitive >information retrieved from postgres tables. >Our app zeros out its associated memory to the process when it is done >with it. The developer was concerned about the >breadcrumbs left in postgress volatile memory in satisfying the query. Well VACUUM is not going to help there, it works on the data stored on disk.
Which would help from the standpoint of shared_buffers... for whatever that's worth.
To answer an earlier comment about zeroing out the free space on the page, it would be trivial to add that, at least for heap pages. Index pages not so much, because you'd have to mess with every index type.
Also, if you're cranking the paranioa level to maximum, you'd want to compile Postgres with the option that over-writes freed memory with 0x7f too. That's meant to help find overruns and other memory access errors, but would have the side effect of nuking the contents of freed memory.
-- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
