"G�ran Thyni" <goran@bildbasen.se> writes:
> Linux can only MAP_SHARED if the file is a *real* file,
> devices or trick like MAP_ANON does only work with MAP_PRIVATE.
Well, this makes some sense: MAP_SHARED implies that the shared memory
will also be accessible to independently started processes, and
to do that you have to have an openable filename to refer to the
data segment by.
MAP_PRIVATE will *not* work for our purposes: according to my copy
of mmap(2):
: If MAP_PRIVATE is set in flags:
: o Modification to the mapped region by the calling process is
: not visible to other processes which have mapped the same
: region using either MAP_PRIVATE or MAP_SHARED.
: Modifications are not visible to descendant processes that
: have inherited the mapped region across a fork().
so privately mapped segments are useless for interprocess communication,
even after we get rid of exec().
mmaping /dev/zero, as has been suggested earlier in this thread,
seems like a really bad idea to me. Would that not imply that
any process anywhere in the system that also decides to mmap /dev/zero
would get its hands on the Postgres shared memory segment? You
can't restrict permissions on /dev/zero to prevent it.
Am I right in thinking that the contents of the shared memory segment
do not need to outlive a particular postmaster run? (If they do, then
we have to mmap a real file anyway.) If so, then MAP_ANON(YMOUS) is
a reasonable solution on systems that support it. On those that
don't support it, we will have to mmap a real file owned by (and only
readable/writable by) the postgres user. Time for another configure
test.
BTW, /dev/zero doesn't exist anyway on HPUX 9.
regards, tom lane