Re: Our naming of wait events is a disaster.
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2020-05-14T19:58:53Z
Lists: pgsql-hackers
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
Commits
-
Mop-up for wait event naming issues.
- 3048898e73c7 13.0 landed
-
Change locktype "speculative token" to "spectoken".
- 474e7da64856 13.0 landed
-
Drop the redundant "Lock" suffix from LWLock wait event names.
- 14a910109126 13.0 landed
-
Rename assorted LWLock tranches.
- 36ac359d3621 13.0 landed
-
Rename SLRU structures and associated LWLocks.
- 5da14938f7bf 13.0 landed
-
Collect built-in LWLock tranche names statically, not dynamically.
- 29c3e2dd5a6a 13.0 landed