Robert Haas <robertmhaas@gmail.com> writes:
> Well, I took a look at this and it turns out not to be very hard, so
> here's a patch. Currently, we allocate 3 semaphore per shared buffer
> and a bunch of others, but the 3 per shared buffer dominates, so you
> end up with ~49k spinlocks for the default of 128MB shared_buffers. I
> chose to peg the number of semaphores at 1024, which is quite small
> compared to the current allocation, but the number of spinlock
> allocations that can be in progress at any given time is limited by
> the number of running backends. Even allowing for the birthday
> paradox, that should be enough to run at least a few dozen backends
> without suffering serious problems due to the multiplexing -
> especially because in real workloads, contention is usually
> concentrated around a small number of spinlocks that are unlikely to
> all be mapped to the same underlying semaphore.
> I'm happy enough with this way forward. Objections?
-1 for the any_spinlock_held business (useless overhead IMO, as it doesn't
have anything whatsoever to do with enforcing the actual coding rule).
And I'd suggest defining NUM_SPINLOCK_SEMAPHORES in pg_config_manual.h,
and maybe dropping SpinlockSemas() altogether in favor of just referencing
the constant. Otherwise this seems reasonable.
regards, tom lane