Re: Our naming of wait events is a disaster.

On Tue, May 12, 2020 at 10:54 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I don't actually understand why the LWLock tranche mechanism is designed
> the way it is.  It seems to be intended to support different backends
> having different sets of LWLocks, but I fail to see why that's a good idea,
> or even useful at all.  In any case, dynamically-created LWLocks are
> clearly out of scope for the documentation.  The problem that I'm trying
> to deal with right now is that even LWLocks that are hard-wired into the
> backend code are difficult to enumerate.  That wasn't a problem before
> we decided we needed to expose them all to user view; but now it is.

If you are using parallel query, your backend might have a DSM segment
that contains LWLocks. Anyone who is not attached to that DSM segment
won't know about them, though possibly they have a different DSM
segment containing a tranche with the same name.

Also, if you are using extensions that use LWLocks, a particular
extension may be loaded into backend A but not backend B. Suppose
backend A has an extension loaded but backend B does not. Then suppose
that A waits for an LWLock and B meanwhile examines pg_stat_activity.

It's hard to come up with totally satisfying solutions to problems
like these, but I think the important thing to remember is that, at
least in the extension case, this is really an obscure corner case.
Normally the same extensions will be loaded everywhere and anything
known to one backend will be known also the others. However, it's not
guaranteed.

I tend to prefer that modules register their own tranches rather than
having a central table someplace, because I like the idea that the
things that a particular module knows about are contained within its
own source files and not spread all over the code base. I think that
we've done rather badly with this in a number of places, lwlock.c
among them, and I don't like it much. It tends to lead to layering
violations, and it also tends to create interfaces that extensions
can't really use. I admit that it's not ideal as far as this
particular problem is concerned, but I don't think that makes it a bad
idea in general. In some sense, the lack of naming consistency here is
a manifestation of an underlying chaos in the code: we've created many
different ways of waiting for things with many different
characteristics and little thought to consistency, and this mechanism
has exposed that underlying problem. The wait state interface is
surely not to blame for the fact that LWLock names and heavyweight
lock types are capitalized inconsistently. In fact, there seem to be
few things that PostgreSQL hackers love more than inconsistent
capitalization, and this is just one of a whole lot of instances of
it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company