Re: [PATCH] Identify LWLocks in tracepoints

On Mon, 28 Dec 2020 at 20:09, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:

> Hi Craig,
>
> On Sat, Dec 19, 2020 at 2:00 PM Craig Ringer
> <craig(dot)ringer(at)enterprisedb(dot)com> wrote:
> >
> > Hi all
> >
> > The attached patch set follows on from the discussion in [1] "Add LWLock
> blocker(s) information" by adding the actual LWLock* and the numeric
> tranche ID to each LWLock related TRACE_POSTGRESQL_foo tracepoint.
> >
> > This does not provide complete information on blockers, because it's not
> necessarily valid to compare any two LWLock* pointers between two process
> address spaces. The locks could be in DSM segments, and those DSM segments
> could be mapped at different addresses.
> >
> > I wasn't able to work out a sensible way to map a LWLock* to any sort of
> (tranche-id, lock-index) because there's no requirement that locks in a
> tranche be contiguous or known individually to the lmgr.
> >
> > Despite that, the patches improve the information available for LWLock
> analysis significantly.
> >
> > Patch 1 fixes a bogus tracepoint where an lwlock__acquire event would be
> fired from LWLockWaitForVar, despite that function never actually acquiring
> the lock.
> >
> > Patch 2 adds the tranche id and lock pointer for each trace hit. This
> makes it possible to differentiate between individual locks within a
> tranche, and (so long as they aren't tranches in a DSM segment) compare
> locks between processes. That means you can do lock-order analysis etc,
> which was not previously especially feasible. Traces also don't have to do
> userspace reads for the tranche name all the time, so the trace can run
> with lower overhead.
> >
> > Patch 3 adds a single-path tracepoint for all lock acquires and
> releases, so you only have to probe the lwlock__acquired and
> lwlock__release events to see all acquires/releases, whether conditional or
> otherwise. It also adds start markers that can be used for timing wallclock
> duration of LWLock acquires/releases.
> >
> > Patch 4 adds some comments on LWLock tranches to try to address some
> points I found confusing and hard to understand when investigating this
> topic.
> >
>
> You sent in your patch to pgsql-hackers on Dec 19, but you did not
> post it to the next CommitFest[1]. If this was intentional, then you
> need to take no action. However, if you want your patch to be
> reviewed as part of the upcoming CommitFest, then you need to add it
> yourself before 2021-01-01 AoE[2]. Thanks for your contributions.
>
> Regards,
>
> [1] https://commitfest.postgresql.org/31/
> [2] https://en.wikipedia.org/wiki/Anywhere_on_Earth
>

Thanks.

CF entry created at https://commitfest.postgresql.org/32/2927/ . I don't
think it's urgent and will have limited review time so I didn't try to
wedge it into the current CF.