Re: [PATCH] Identify LWLocks in tracepoints

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>

To: Craig Ringer <craig.ringer@enterprisedb.com>

Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>

Date: 2021-01-22T11:02:11Z

Lists: pgsql-hackers

On 2021-01-14 09:39, Craig Ringer wrote:
> On Thu, 14 Jan 2021 at 15:56, Peter Eisentraut 
> <peter.eisentraut@enterprisedb.com 
> <mailto:peter.eisentraut@enterprisedb.com>> wrote:
> 
>     On 2020-12-19 06:00, Craig Ringer wrote:
>      > Patch 1 fixes a bogus tracepoint where an lwlock__acquire event
>     would be
>      > fired from LWLockWaitForVar, despite that function never actually
>      > acquiring the lock.
> 
>     This was added in 68a2e52bbaf when LWLockWaitForVar() was first
>     introduced.  It looks like a mistake to me too, but maybe Heikki wants
>     to comment.
> 
> 
> I'm certain it's a copy/paste bug.

I have committed that patch.

Commits

Emit dummy statements for probes.d probes when disabled
- 0d204a4b09f7 13.3 landed
- fa8fbadb934b 14.0 landed
Prevent lwlock dtrace probes from unnecessary work
- e48ce7ef0ef8 13.3 landed
- b94409a02f61 14.0 landed
doc: Fix typo in logicaldecoding.sgml.
- 5fe83adad9ef 14.0 cited
Move lwlock-release probe back where it belongs
- 96ae658e6238 14.0 landed
Remove bogus tracepoint
- 09418bed67a7 14.0 landed
Simplify LWLock tranche machinery by removing array_base/array_stride.
- 3761fe3c20bb 10.0 cited
Improve LWLock scalability.
- ab5194e6f617 9.5.0 cited