From: Tom Lane <tgl@sss.pgh.pa.us>
To: Isaac Morland <isaac.morland@gmail.com>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
        Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Our naming of wait events is a disaster.
In-reply-to: 
 <CAMsGm5ci68RWekX+JCA9QJzoqBk0Q08rJa2akv0eR1mvpURA2w@mail.gmail.com>
References: <20200512202726.GA31125@alvherre.pgsql>
 <9871.1589321468@sss.pgh.pa.us>
 <CAMsGm5ci68RWekX+JCA9QJzoqBk0Q08rJa2akv0eR1mvpURA2w@mail.gmail.com>
Comments: In-reply-to Isaac Morland <isaac.morland@gmail.com>
	message dated "Tue, 12 May 2020 21:16:40 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5597.1589338488.1@sss.pgh.pa.us>
Date: Tue, 12 May 2020 22:54:48 -0400
Message-ID: <5598.1589338488@sss.pgh.pa.us>
Precedence: bulk

Isaac Morland <isaac.morland@gmail.com> writes:
> ...  I'm wondering because it seems
> like it might be helpful to have a system view which gives all the wait
> event types, names, and descriptions. Maybe even add a column for which
> extension (or core) it came from. The documentation could then just explain
> the general situation and point people at the system view to see exactly
> which wait types exist in their system.

There's certainly an argument for doing things like that, but I think it'd
be a net negative in terms of quality and consistency of documentation.
We'd basically be deciding those are non-goals.

Of course, ripping out table 27.4 altogether would be a simple solution
to the formatting problem I started with ;-).  But it doesn't really
seem like the answer we want.

> Of course if the names get passed in ad hoc then such a view could only
> show the types that happen to have been created up to the moment it is
> queried, which would defeat the purpose.

Yes, exactly.

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.

			regards, tom lane