Isaac Morland <isaac.morl...@gmail.com> writes: > ... 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.
There's certainly an argument for doing things like that, but I think it'd be a net negative in terms of quality and consistency of documentation. We'd basically be deciding those are non-goals. Of course, ripping out table 27.4 altogether would be a simple solution to the formatting problem I started with ;-). But it doesn't really seem like the answer we want. > 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. Yes, exactly. I don't actually understand why the LWLock tranche mechanism is designed the way it is. It seems to be intended to support different backends having different sets of LWLocks, but I fail to see why that's a good idea, or even useful at all. In any case, dynamically-created LWLocks are clearly out of scope for the documentation. The problem that I'm trying to deal with right now is that even LWLocks that are hard-wired into the backend code are difficult to enumerate. That wasn't a problem before we decided we needed to expose them all to user view; but now it is. regards, tom lane