Re: [PATCH] Identify LWLocks in tracepoints

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Identify LWLocks in tracepoints
Date: 2021-03-19 20:21:24
Message-ID: 49d46450-3cb4-f537-4856-1b268c327843@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-03-19 20:29:14 Re: pglz compression performance, take two
Previous Message Tom Lane 2021-03-19 20:20:09 Re: [HACKERS] Custom compression methods