Hi Craig,
On Sat, Dec 19, 2020 at 2:00 PM Craig Ringer
<craig.ringer@enterprisedb.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*
pointersbetween two process address spaces. The locks could be in DSM segments, and those DSM segments could be mapped
atdifferent 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
requirementthat 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
functionnever actually acquiring the lock.
>
> Patch 2 adds the tranche id and lock pointer for each trace hit. This makes it possible to differentiate between
individuallocks 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'thave 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__acquiredand lwlock__release events to see all acquires/releases, whether conditional or otherwise. It also adds
startmarkers 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
wheninvestigating 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
--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/
