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