I was trying to measure whether unnamed POSIX semaphores are any faster
or slower than the SysV kind. Plain pgbench is not very helpful for
determining this, because we've optimized the system to the point that
you don't hit semop waits all that often. So I tried this:
configure USE_UNNAMED_POSIX_SEMAPHORES=1 --disable-cassert --disable-spinlocks
--disable-atomics
figuring that that would stress the semop paths nicely. But what I find
is that the database locks up after a few seconds of running "pgbench -S
-c 20 -j 20 bench" on an 8-core RHEL6 machine.
I think what is happening is that there are circular assumptions that end
up trying to implement a spinlock in terms of a spinlock, or otherwise
somehow recursively use the process's semaphore. It's a bit hard to tell
though because the atomics code is such an underdocumented rat's nest of
#ifdefs.
Curiously, I did not see such a hang with regular SysV semaphores.
That may be just a timing thing, or it may have something to do with
POSIX semaphores being actually futexes on this platform (so that there
is state inside the process not outside it).
No hang observed without --disable-atomics, either.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
