Re: CompactCheckpointerRequestQueue versus pad bytes

On Sun, Jul 15, 2012 at 5:36 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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