From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Isaac Morland <isaac.morland@gmail.com>,
        Alvaro Herrera <alvherre@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Our naming of wait events is a disaster.
In-reply-to: 
 <CA+TgmoaLEdDHpTiKtNkjD23WH3zYnj+hLiW4ZC0tZuLpSf7xeQ@mail.gmail.com>
References: <20200512202726.GA31125@alvherre.pgsql>
 <9871.1589321468@sss.pgh.pa.us>
 <CAMsGm5ci68RWekX+JCA9QJzoqBk0Q08rJa2akv0eR1mvpURA2w@mail.gmail.com>
 <5598.1589338488@sss.pgh.pa.us>
 <CA+TgmoZ8qOUCXGp5RC=Bc2Wo7AOSNKnru56yghfzu-X9O=7Vjw@mail.gmail.com>
 <11332.1589482482@sss.pgh.pa.us>
 <CA+TgmoaLEdDHpTiKtNkjD23WH3zYnj+hLiW4ZC0tZuLpSf7xeQ@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Thu, 14 May 2020 15:37:07 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14022.1589486333.1@sss.pgh.pa.us>
Date: Thu, 14 May 2020 15:58:53 -0400
Message-ID: <14023.1589486333@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> That being said, my view of this system is that it's good to document
> the wait events that we have, but also that there are almost certainly
> going to be cases where we can't say a whole lot more than "go read
> the code," or at least not without an awful lot of work.

Can't disagree with that.

> I think
> there's a reasonable chance that someone who sees a lot of ClientRead
> or DataFileWrite wait events will have some idea what kind of problem
> is indicated, even without consulting the documentation and even
> moreso if we have some good documentation which they can consult. But
> I don't know what anybody's going to do if they see a lot of
> OldSerXidLock or AddinShmemInitLock contention.

I submit that at least part of the problem is precisely one of crappy
naming.  I didn't know what OldSerXidLock did either, until yesterday
when I dug into the code to find out.  If it's named something like
"SerialSLRULock", then at least somebody who has heard of SLRUs will
have an idea of what is indicated.  And we are exposing the notion
of SLRUs pretty prominently in the monitoring docs as of v13, so that's
not an unreasonable presumption.

			regards, tom lane