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. Of course you can't count on malloc() to return zero'd memory, but that's because the process might get a page (all zeros) from the OS, allocate it, free it, and then reallocate it for an unrelated purpose. But we have no method that I know of for freeing shared memory, and even if we did, the memory used by the fsync queue is allocated during startup and therefore presumably prior to any hypothetical ShmemFree operations that might occur subsequently. So I'm having a hard time understanding under what imaginable set of circumstances this might break. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers