Re: [PATCH] Identify LWLocks in tracepoints

Peter Eisentraut <peter.eisentraut@enterprisedb.com>

From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2021-04-14T13:20:59Z
Lists: pgsql-hackers
On 12.04.21 07:46, Craig Ringer wrote:
>      > 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.

This whole thread is now obviously moved to consideration for PG15, but 
I did add an open item about this particular issue 
(https://wiki.postgresql.org/wiki/PostgreSQL_14_Open_Items, search for 
"dtrace").  So if you could produce a separate patch that adds the 
_ENABLED guards targeting PG14 (and PG13), that would be helpful.



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.