Re: [PATCH] Identify LWLocks in tracepoints

On Wed, 14 Apr 2021, 22:29 Robert Haas, <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Apr 13, 2021 at 10:42 PM Craig Ringer
> <craig(dot)ringer(at)enterprisedb(dot)com> wrote:
> > I'd really love it if a committer could add an explanatory comment or
> > two in the area though. I'm happy to draft a comment patch if anyone
> > agrees my suggestion is sensible. The key things I needed to know when
> > studying the code were:
> > [...]
>
> I'm willing to review a comment patch along those lines.
>

Cool. I'll draft soon.

I since noticed that some of the info is present, but it's in lwlock.h
whereas in Pg comment detail is more often than not in the .c file.

I prefer it in headers myself anyway, since it's more available to tools
like doxygen. I'll add a few "see lwlock.h" hints, a short para about
appropriate lwlock use in the .c into comment etc and post on a separate
thread soon.

> > I'm actually inclined to revise the patch I sent in order to *remove*
> > the LWLock name from the tracepoint argument.
>

Reducing the overheads is good, but I have no opinion on what's
> important for people doing tracing, because I am not one of those
> people.
>

Truthfully I'm not convinced anyone is "those people" right now. I don't
think anyone is likely to be making serious use of them due to their
limitations.

Certainly that'll be the case for the txn ones which are almost totally
useless. They only track the localxid lifecycle, they don't track real txid
allocation, WAL writing, commit (wal or shmem), etc.