On Mon, Jan 6, 2014 at 2:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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).
Hmm. I thought that was a pretty well-aimed bullet myself; why do you think that it isn't? I don't particularly mind ripping it out, but it seemed like a good automated test to me. > 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. As far as pg_config_manual.h is concerned, is this the sort of thing you have in mind? #ifndef HAVE_SPINLOCKS #define NUM_SPINLOCK_SEMAPHORES 1024 #endif -- 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: http://www.postgresql.org/mailpref/pgsql-hackers
