On 16.07.2012 18:24, Robert Haas wrote:
On Sun, Jul 15, 2012 at 5:36 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
We could fairly cheaply dodge the problem with padding after ForkNumber
if we were to zero out the whole request array at shmem initialization,
so that any such pad bytes are guaranteed zero. However, padding in
RelFileNodeBackend would be more annoying to deal with, and at least
in the current instantiation of those structs it's probably impossible
anyway. Should we document those structs as required to not contain
any padding, or do what's needful in checkpointer.c to not depend on
there not being padding?
I would expect that every method we could devise for allocating a
shared memory segment would produce all-zero bytes. There was a time
long ago when the OS would simply hand over previously-freed pages
with their existing contents, but I believe that was recognized as a
security problems more than 20 years ago - maybe 30 - and I can't
believe there is any OS we care about supporting that fails to zero
pages before handing them out.
I wouldn't rely on that, though. I wouldn't be surprised if there was
some debugging flag or similar that initialized all pages to random
values or 0xdeadbeef or something, before handing them out to the
application. We could easily zero all shared memory on allocation
ourselves, though.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
