James Hilliard <james.hillia...@gmail.com> writes:
> from my understanding due to mach semantics a number of the sanity checks
> we are doing for sysv shmem are probably unnecessary when using mach
> API's due to the mach port task bindings(mach_task_self()) effectively
> ensuring our maps are already task bound and won't conflict with other tasks.
Really? If so, this whole patch is pretty much dead in the water,
because the fact that sysv shmem is globally accessible is exactly
why we use it (well, that and the fact that you can find out how many
processes are attached to it). It's been a long time since we cared
about sysv shmem as a source of shared storage. What we really use
it for is as a form of mutual exclusion, i.e. being able to detect
whether any live children remain from a dead postmaster. That is,
PGSharedMemoryIsInUse is not some minor ancillary check, it's the main
reason this module exists at all. If POSIX-style mmap'd shmem had the
same capability we'd likely have dropped sysv altogether long ago.
I've occasionally wondered if we should take another look at file locking
as a mechanism for ensuring only one postmaster+children process group
can access a data directory. Back in the day it was too untrustworthy,
but maybe that has changed.
regards, tom lane
