Our "fallback" atomics implementation doesn't actually work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Our "fallback" atomics implementation doesn't actually work
Date: 2016-10-05 18:01:05
Message-ID: 14947.1475690465@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-10-05 18:05:10 Re: Our "fallback" atomics implementation doesn't actually work
Previous Message Robert Haas 2016-10-05 17:22:13 Re: Cardinality estimation for group by