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.
I expect there is a reason why this hasn’t been suggested, but just in case it is at all helpful:
When do these names get created? That is, do all the wait types get created and registered on startup, or is it more like whenever something needs to do something the name gets passed in ad hoc? 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. This would require every instance where a type is registered to pass an additional parameter — the description, as currently seen in the table in the documentation.
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. And I can think of a few potential reasons why this might not work at all, starting with the need to re-write every example of registering a new type to provide the documentation string for the view.
Inspiration due to pg_setting, pg_config, pg_available_extensions and pg_get_keywords ().