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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: michael@paquier.xyz, masao.fujii@oss.nttdata.com, amit.kapila16@gmail.com, pasim@vmware.com, pgsql-hackers@lists.postgresql.org
Date: 2020-06-03T18:35:29Z
Lists: pgsql-hackers 
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> I looked through 224 locations where SpinLockAcquire and found some.

Yeah, I made a similar scan and arrived at about the same conclusions.
I think that the memcpy and strlcpy calls are fine; at least, we've got
to transport data somehow and it's not apparent why those aren't OK ways
to do it.  The one use of StrNCpy is annoying from a cosmetic standpoint
(mainly because it's Not Like Anywhere Else) but I'm not sure it's worth
changing.

The condition-variable code has a boatload of spinlocked calls of the
proclist functions in proclist.h.  All of those are straight-line code
so they're okay performance wise, but I wonder if we shouldn't add a
comment to that header pointing out that its functions must not throw
errors.

The only other thing I remain concerned about is some instances of atomic
operations inside spinlocks, which I started a separate thread about [1].

			regards, tom lane

[1] https://www.postgresql.org/message-id/1141819.1591208385%40sss.pgh.pa.us

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.