On Mon, 22 Mar 2021 at 17:00, Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote:
> On 20.03.21 01:29, Craig Ringer wrote: > > 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 > > < > 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. > > We do that. (It's -G.) > Huh. I could've sworn we didn't. My mistake, it's there in src/backend/Makefile . In that case I'll amend the patch to use semaphore guards. (On a side note, systemtap's semaphore support is actually a massive pain. The way it's implemented in <sys/sdt.h> means that a single compilation unit may not use both probes.d style markers produced by the dtrace script and use regular DTRACE_PROBE(providername,probename) preprocessor macros. If it attempts to do so, the DTRACE_PROBE macros will emit inline asm that tries to reference probename_semaphore symbols that will not exist, resulting in linker errors or runtime link errors. But that's really a systemtap problem. Core PostgreSQL doesn't use any explicit DTRACE_PROBE(...), STAP_PROBE(...) etc.)
