Chris Marcellino <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match