Robert Haas <robertmhaas@gmail.com> writes:
> Removing some of these spinlocks and replacing them with LWLocks might
> also be worth considering.
When I went through the existing spinlock stanzas, the only thing that
really made me acutely uncomfortable was the chunk in pg_stat_statement's
pgss_store(), lines 1386..1438 in HEAD. In the first place, that's
pushing the notion of "short straight-line code" well beyond reasonable
bounds. Other processes could waste a fair amount of time spinning while
the lock holder does all this arithmetic; not to mention the risk of
exhausting one's CPU time-slice partway through. In the second place,
a chunk of code this large could well allow people to make modifications
without noticing that they're inside a spinlock, allowing future coding
violations to sneak in.
Not sure what we want to do about it though. An LWLock per pgss entry
probably isn't gonna do. Perhaps we could take a cue from your old
hack with multiplexed spinlocks, and map the pgss entries onto some
fixed-size pool of LWLocks, figuring that the odds of false conflicts
are small as long as the pool is bigger than MaxBackends.
regards, tom lane
