On Mon, Jul 16, 2012 at 11:44 AM, Heikki Linnakangas <heikki.linnakan...@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 use of 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 associated data 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 set using 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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers