Horton

Re: [PATCH] Identify LWLocks in tracepoints

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-03-19T20:21:24Z
Lists: pgsql-hackers 
On 18.03.21 07:34, Craig Ringer wrote:
> The main reason I didn't want to add more tracepoints than were strictly 
> necessary is that Pg doesn't enable the systemtap semaphores feature, so 
> right now we do a T_NAME(lock) evaluation each time we pass a tracepoint 
> if --enable-dtrace is compiled in, whether or not anything is tracing. 
> This was fine on pg11 where it was just:
> 
> #define T_NAME(lock) \
>          (LWLockTrancheArray[(lock)->tranche])
> 
> but since pg13 it instead expands to
> 
>          GetLWTrancheName((lock)->tranche)
> 
> where GetLWTrancheName isn't especially trivial. We'll run that function 
> every single time we pass any of these tracepoints and then discard the 
> result, which is ... not ideal. That applies so long as Pg is compiled 
> with --enable-dtrace. I've been meaning to look at enabling the 
> systemtap semaphores feature in our build so these can be wrapped in 
> unlikely(TRACE_POSTGRESQL_LWLOCK_RELEASE_ENABLED()) guards, but I wanted 
> to wrap this patch set up first as there are some complexities around 
> enabling the semaphores feature.

There is already support for that.  See the documentation at the end of 
this page: 
https://www.postgresql.org/docs/devel/dynamic-trace.html#DEFINING-TRACE-POINTS

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.