Re: [PATCH] Identify LWLocks in tracepoints

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [PATCH] Identify LWLocks in tracepoints
Дата
Msg-id CAGRY4nyZJ0R3wocgHT2efwROZn4a687WKhYjaNaCQ8UDXO3wZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Identify LWLocks in tracepoints  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: [PATCH] Identify LWLocks in tracepoints
Список pgsql-hackers
On Mon, 22 Mar 2021 at 17:00, Peter Eisentraut <peter.eisentraut@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.)

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] force_parallel_mode and GUC categories
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Simplify backend terminate and wait logic in postgres_fdw test