On Jun 27, 2012, at 7:34 AM, Robert Haas wrote:
> On Wed, Jun 27, 2012 at 12:00 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> So, here's a patch. Instead of using POSIX shmem, I just took the
>>> expedient of using mmap() to map a block of MAP_SHARED|MAP_ANONYMOUS
>>> memory. The sysv shm is still allocated, but it's just a copy of
>>> PGShmemHeader; the "real" shared memory is the anonymous block. This
>>> won't work if EXEC_BACKEND is defined so it just falls back on
>>> straight sysv shm in that case.
>>
>> Um. I hadn't thought about the EXEC_BACKEND interaction, but that seems
>> like a bit of a showstopper. I would not like to give up the ability
>> to debug EXEC_BACKEND mode on Unixen.
>>
>> Would Posix shmem help with that at all? Why did you choose not to
>> use the Posix API, anyway?
>
> It seemed more complicated. If we use the POSIX API, we've got to
> have code to find a non-colliding name for the shm, and we've got to
> arrange to clean it up at process exit. Anonymous shm doesn't require
> a name and goes away automatically when it's no longer in use.
>
> With respect to EXEC_BACKEND, I wasn't proposing to kill it, just to
> make it continue to use a full-sized sysv shm.
>
I solved this by unlinking the posix shared memory segment immediately after creation. The file descriptor to the
sharedmemory is inherited, so, by definition, only the postmaster children can access the memory. This ensures that
sharedmemory cleanup is immediate after the postmaster and all children close, as well. The fcntl locking is not
requiredto protect the posix shared memory- it can protect itself.
Cheers,
M