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: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-05-12T22:11:08Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > (Didn't we have a patch to generate the table programmatically?) Having now looked around a bit at where the names come from, I think such a patch would be impossible as things stand, which is a pity because as-things-stand is a totally unmaintainable situation. Anybody at all can call LWLockRegisterTranche and thereby create a new name that ought to be listed in the SGML table. Apparently, somebody grepped for such calls and put all the ones that existed at the time into the table; unsurprisingly, the results are already out of date. Several of the hard-wired calls in RegisterLWLockTranches() are not reflected in the SGML table AFAICS. Or, if you don't want to call LWLockRegisterTranche, you can instead call RequestNamedLWLockTranche. Whee. At least there are none of those in the core code. However, we do have both autoprewarm and pg_stat_statements calling these things from contrib. That raises a policy question, or really two of them: should contrib code be held to the standards we're going to set forth for tranche names chosen by core code? And should contrib-created tranche names be listed in chapter 27's table? (If not, should the individual contrib modules document their additions?) We could make things a little better perhaps if we got rid of all the cowboy calls to LWLockRegisterTranche and had RegisterLWLockTranches make all of them using a single table of names, as it already does with MainLWLockNames[] but not the other ones. Then it'd be possible to have documentation beside that table warning people to add entries to the SGML docs; and even for the people who can't be bothered to read comments, at least they'd be adding names to a list of names that would give them some precedent and context for how to choose a new name. I think 50% of the problem right now is that if you just write a random new call to LWLockRegisterTranche in a random new place, you have no context about what the tranche name should look like. Even with all the names declared in some reasonably centralized place(s), we'd be a long way from making the SGML tables programmatically, because we'd not have text descriptions for the wait events. I can imagine extending the source-code conventions a bit to include those strings there, but I'm doubtful that it's worth the trouble. 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