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: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, David Steele <david@pgmasters.net>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-04-14T02:45:16Z
Lists: pgsql-hackers 
On Wed, 14 Apr 2021 at 10:41, Craig Ringer
<craig.ringer@enterprisedb.com> wrote:
> On Wed, 14 Apr 2021 at 02:25, Robert Haas <robertmhaas@gmail.com> wrote:
> > You could try to identify locks by pointer addresses, but that's got
> > security hazards and the addreses aren't portable across all the
> > backends involved in the parallel query because of how DSM works, so
> > it's not really that helpful in terms of matching stuff up.
>
> What I'm doing now is identifying them by LWLock* across backends. I
> keep track of DSM segment mappings in each backend inside the trace
> script and I relocate LWLock* pointers known to be inside DSM segments
> relative to a dummy base address so they're equal across backends.

BTW, one of the reasons I did this was to try to identify BDR and
pglogical code that blocks or sleeps while holding a LWLock. I got
stuck on that for other reasons, so it didn't go anywhere, but those
issues are now resolved so I should probably return to it at some
point.

It'd be a nice thing to be able to run on postgres itself too.

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.