Chris Marcellino <maps@levelview.com> writes:
> As Tom pointed out, the code I posted yesterday is not robust enough
> for general consumption. I'm working on a better solution, which will
> likely involve using a very small SysV shmem segment as a mutex of
> sorts (as Michael Paesold suggested).
One problem with Michael's idea is that it gives up one of the better
arguments for having a POSIX option, namely to allow us to run on
platforms where SysV shmem support is not there at all.
I'm not sure whether the idea can be implemented without creating new
failure modes; that will have to wait on seeing a patch. But the
strength of the coupling between the SysV and POSIX segments is
certainly going to be a red-flag item to look at.
>> Then, how about semaphores? When I just do configure, PostgreSQL
>> seems to use SysV semaphores. But POSIX semaphore implementation is
>> prepared in src/backend/port/posix_sema.c. Why isn't it used by
>> default? Does it have any problem?
> In this case, semaphore usage is unrelated to shared memory
> shortages. Also, on many platforms the posix_sema's code is used.
> Either way, Essentially, no one is running out of shared memory due
> to semaphores.
AFAIK the only platform where the POSIX sema code is really used is
Darwin (OS X), and it is not something I'd use there if I had a choice.
The problem with it is that *every* semaphore corresponds to an open
file handle in the postmaster that has to be inherited by *every* forked
child. So N backend slots cost you O(N^2) in kernel filehandles and
process fork overhead, plus if N is big you're taking a serious hit in
the number of disk files any one backend can have open. This problem
may be specific to Darwin's implementation of the POSIX spec, but it's
real enough there. If you trawl the archives you'll probably notice a
lack of people running big Postgres installations on Darwin, and this is
why.
regards, tom lane
