Re: Spinlocks and semaphores in 9.2 and 9.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Spinlocks and semaphores in 9.2 and 9.3
Date: 2016-04-18 15:34:51
Message-ID: 25803.1460993691@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-04-18 11:24:07 -0400, Tom Lane wrote:
>> (The thing that gave me pause about this was noticing that I could not
>> start two such postmasters concurrently on my RHEL6 box, without changing
>> the default system limits on number of SysV semaphores.)

> Hm, is that different before/after the patch? Because afaics at around
> NBuffers = 1000, the number of semaphores should be lower after the
> patch?

Yeah, that was probably the argument we used before. But it's true that a
postmaster built with --disable-spinlocks is harder to test than one built
without (because you're going from ~100 semas to ~1100 semas, at default
configuration). If we believe that the main real use-case for this switch
is testing, that's not a very nice property.

The bottom line IMO is that --disable-spinlocks is actually not that awful
for low-stress, low-concurrency scenarios; for example, it doesn't change
the runtime of make installcheck-parallel very much for me. On the other
hand, for high-concurrency scenarios you'd darn well better get a real
spinlock implementation. Given that sort of scope of use, it seems like
a hundred or so underlying semas should be plenty, and it'd be less likely
to cause operational problems than 1024.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-04-18 15:35:05 Re: Spinlocks and semaphores in 9.2 and 9.3
Previous Message Pavel Stehule 2016-04-18 15:30:26 Re: Parser extensions (maybe for 10?)