Re: CompactCheckpointerRequestQueue versus pad bytes

On Mon, Jul 16, 2012 at 11:44 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> 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.

Well, the documentation for mmap (which we're currently using) on Linux says:
      MAP_ANONYMOUS             The mapping is not backed by any file; its contents are initial‐             ized to
zero. The fd and offset arguments are ignored; however,             some implementations require fd to be -1  if
MAP_ANONYMOUS (or             MAP_ANON)  is specified, and portable applications should ensure             this.  The
useof MAP_ANONYMOUS in conjunction  with  MAP_SHARED             is only supported on Linux since kernel 2.4. 

shmget says:
      When  a new shared memory segment is created, its contents are initial‐      ized to zero values, and its
associateddata structure,  shmid_ds  (see      shmctl(2)), is initialized as follows: 

And shm_open says:
                 A new shared memory object initially has zero length  —  the                 size of the object can be
setusing ftruncate(2).  The newly                 allocated bytes of a shared memory object are  automatically
      initialized to 0. 

The documentation on MacOS X isn't quite as explicit, but I'd still be
astonished if we found any other behavior.  TBH, I'd be kind of
surprised if this is the only place in our code base that relies on
the initial contents of shared memory being all-zeros.  If we really
care about that we probably ought to make --enable-cassert write
0xdeadbeef all over the whole shared-memory segment on startup, or
something like that, because otherwise it's only a matter of time
before someone will break it.  Personally I'd like to see some
evidence that the problem is more than strictly hypothetical before we
spend time on it, though.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company