Horton

Re: [PATCH] Identify LWLocks in tracepoints

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>, Craig Ringer <craig.ringer@enterprisedb.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-05-11T17:35:42Z
Lists: pgsql-hackers 
Hi,

On 2021-05-10 09:46:02 -0700, Andres Freund wrote:
> No worries - I knew that I'd have to do this at some point, even though
> I hadn't planned to do that today... I should have all of them green
> before end of today.
> 
> I found that I actually can build LLVM 3.9 directly, as clang-6 can
> still build it directly (wheras the oldest gcc still installed can't
> build it directly). So it's a bit less painful than I thought at first
> 
> The 3.9 instances (phycodurus, dragonet) tests are running right now,
> and I'm fairly sure they'll pass (most of a --noreport --nostatus run
> passed). Going forward building LLVM 4,5,6 now - the later versions take
> longer...

Looks like it's all clear now. All but the results for 11 had cleared up
until yesterday evening, and the rest came in ok over night.

Greetings,

Andres Freund

Commits

  1. Emit dummy statements for probes.d probes when disabled

  2. Prevent lwlock dtrace probes from unnecessary work

  3. doc: Fix typo in logicaldecoding.sgml.

  4. Move lwlock-release probe back where it belongs

  5. Remove bogus tracepoint

  6. Simplify LWLock tranche machinery by removing array_base/array_stride.

  7. Improve LWLock scalability.