On Mon, 28 Dec 2020 at 20:09, Masahiko Sawada <sawada.m...@gmail.com> wrote:
> Hi Craig, > > On Sat, Dec 19, 2020 at 2:00 PM Craig Ringer > <craig.rin...@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* 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.
