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>, pgsql-hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>

Date: 2021-01-14T07:56:47Z

Lists: pgsql-hackers

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.

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