Re: Switch to unnamed POSIX semaphores as our preferred sema code? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Switch to unnamed POSIX semaphores as our preferred sema code?
Date
Msg-id CA+TgmoZ-3UFcD-qBZevXLiw-_S3zm2xHgSy+Oa7-BCM+7g6_Sw@mail.gmail.com
Whole thread Raw
In response to Re: Switch to unnamed POSIX semaphores as our preferred sema code?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Switch to unnamed POSIX semaphores as our preferred sema code?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Switch to unnamed POSIX semaphores as our preferred sema code?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Oct 6, 2016 at 9:46 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Can anyone think of a test case that would stress semaphore operations
> more heavily, without being unrealistic?

I think it's going to be pretty hard to come up with a non-artificial
test case that has exhibits meaningful lwlock contention on an 8-core
system.  If you go back to 9.1, before we had fast-path locking, you
can do it, because the relation locks and vxid locks do cause
noticeable contention on the lock manager locks in that version.
Alternatively, you might try something like "pgbench -n -S -c $N -j
$N" with a scale factor that doesn't fit in shared buffers.  This
probably won't produce significant contention because there are 128
LWLocks and only 8 cores, but you could reduce the number of buffer
mapping LWLocks to, say, 4 and then you'd probably hit it fairly hard.

Alternatively, get a bigger box.  :-)

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: pgbench vs. wait events
Next
From: Christoph Berg
Date:
Subject: Re: PostgreSQL - Weak DH group