On Tue, Apr 13, 2021 at 10:42 PM Craig Ringer <craig.rin...@enterprisedb.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: > > * A LWLock* is always part of a tranche, but locks within a given > tranche are not necessarily co-located in memory, cross referenced or > associated in any way. > * A LWLock tranche does not track how many LWLocks are in the tranche > or where they are in memory. It only groups up LWLocks into categories > and maps the tranche ID to a name. > * Not all LWLocks are part of the main LWLock array; others can be > embedded in shmem structs elsewhere, including in DSM segments. > * LWLocks in DSM segments may not have the same address between > different backends, because the DSM base address can vary, so a > LWLock* cannot be reliably compared between backends unless you know > it's in the main LWLock array or in static shmem. > > Having that info in lwlock.c near the tranche management code or the > tranche and main lwlock arrays would've been very handy.
I'm willing to review a comment patch along those lines. > I'm actually inclined to revise the patch I sent in order to *remove* > the LWLock name from the tracepoint argument. At least for the > fast-path tracepoints on start-of-acquire and end-of-acquire. I think > it's probably OK to report it in the lock wait tracepoints, which is > where it's most important to have anyway. So the tracepoint will > always report the LWLock* and tranche ID, but it won't report the > tranche name for the fast-path. I'll add trace events for tranche ID > registration, so trace tools can either remember the tranche ID->name > mappings from there, or capture them from lock wait events and > remember them. > > Reasonable? That way we retain the most important trace functionality, > but we reduce the overheads. 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. -- Robert Haas EDB: http://www.enterprisedb.com
