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
-
Fix instance of elog() called while holding a spinlock
- 4a9809e34d09 9.5.23 landed
- e7a134b5817b 9.6.19 landed
- 5ed8b4a981ed 10.14 landed
- b41a85f53317 11.9 landed
- 03aa25b6e34b 12.4 landed
- c1669fd5812a 13.0 landed
-
Don't call palloc() while holding a spinlock, either.
- 3d474a07934c 12.4 landed
- f88bd3139f3e 13.0 landed
- 7a8cb4a61e7e 11.9 landed
- 0c735c686a90 10.14 landed
-
Don't call elog() while holding spinlock.
- caa3c4242cf8 13.0 landed