On Sat, 20 Mar 2021, 04:21 Peter Eisentraut, < peter.eisentr...@enterprisedb.com> wrote:
> > 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 Pretty sure it won't work right now. To use systemtap semaphores (the _ENABLED macros) you need to run dtrace -g to generate a probes.o then link that into postgres. I don't think we do that. I'll double check soon.
