Re: Spinlocks and semaphores in 9.2 and 9.3
От | Tom Lane |
---|---|
Тема | Re: Spinlocks and semaphores in 9.2 and 9.3 |
Дата | |
Msg-id | 25803.1460993691@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Spinlocks and semaphores in 9.2 and 9.3 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Spinlocks and semaphores in 9.2 and 9.3
|
Список | pgsql-hackers |
Andres Freund <andres@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. regards, tom lane
В списке pgsql-hackers по дате отправления: