On Mon, Apr 18, 2016 at 11:53 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Apr 18, 2016 at 11:34 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Andres Freund <and...@anarazel.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.
> I suppose that's probably true.  I thought surely any system worth its
> salt wouldn't have a problem with 1024 semaphores, but a quick Google
> search for "hp-ux semmns" turned up this page:

Oops, hit send too soon.


That's from 2007 and indicates a default maximum of 2048.  So it would
be fairly easy to hit the limit.

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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to