Horton

Re: [PATCH] Identify LWLocks in tracepoints

Craig Ringer <craig.ringer@enterprisedb.com>

View thread View on postgr.es
From: Craig Ringer <craig.ringer@enterprisedb.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Date: 2021-01-14T08:39:12Z
Lists: pgsql-hackers 
On Thu, 14 Jan 2021 at 15:56, Peter Eisentraut <
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.

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.