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