Re: elog(DEBUG2 in SpinLocked section.

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, masao(dot)fujii(at)oss(dot)nttdata(dot)com, amit(dot)kapila16(at)gmail(dot)com, pasim(at)vmware(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: elog(DEBUG2 in SpinLocked section.
Date: 2020-06-17 00:27:36
Message-ID: 20200617002736.3m6k5dh3eetwrmup@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-06-16 19:46:29 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2020-06-17 00:31:48 Re: language cleanups in code and docs
Previous Message Alvaro Herrera 2020-06-17 00:09:26 Re: Add A Glossary