Horton

Re: elog(DEBUG2 in SpinLocked section.

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Amit Kapila <amit.kapila16@gmail.com>, pasim@vmware.com, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-06-09T17:59:44Z
Lists: pgsql-hackers 
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

Commits

  1. Fix instance of elog() called while holding a spinlock

  2. Don't call palloc() while holding a spinlock, either.

  3. Don't call elog() while holding spinlock.