Re: elog(DEBUG2 in SpinLocked section.

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Michael Paquier <michael@paquier.xyz>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, masao.fujii@oss.nttdata.com, amit.kapila16@gmail.com, pasim@vmware.com, pgsql-hackers@lists.postgresql.org
Date: 2020-06-17T00:27:36Z
Lists: pgsql-hackers
Hi,

On 2020-06-16 19:46:29 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I experimented with making the compiler warn about about some of these
> > kinds of mistakes without needing full test coverage:
>
> > I was able to get clang to warn about things like using palloc in signal
> > handlers, or using palloc while holding a spinlock. Which would be
> > great, except that it doesn't warn when there's an un-annotated
> > intermediary function. Even when that function is in the same TU.
>
> Hm.  Couldn't we make "calling an un-annotated function" be a violation
> in itself?

I don't see a way to do that with these annotations, unfortunately.

https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
https://clang.llvm.org/docs/AttributeReference.html#acquire-capability-acquire-shared-capability


> Certainly in the case of spinlocks, what we want is pretty
> nearly a total ban on calling anything at all.  I wouldn't cry too hard
> about having a similar policy for signal handlers.

It'd be interesting to try and see how invasive that'd be, if it were
possible to enforce. But...

Greetings,

Andres Freund



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.