On Tue, Sep 15, 2015 at 2:44 PM, and...@anarazel.de <and...@anarazel.de> wrote: > On 2015-09-15 14:39:51 -0400, Robert Haas wrote: >> We could, but since that would be strictly more annoying and less >> flexible than what we've already got, why would we? > > I don't find the current approach of having to define tranches in every > backend all that convenient.
Sure. That's why I proposed a way to define them across all backends during postmaster startup. However, I'd like that way to be in addition to what works now, not instead of it. That way, you can do it the convenient way if it applies, and the inconvenient way is still there if you really need it. > It also completely breaks down if you want > to display locks from tranches that are only visible within a subset of > the backends - not that unlikely given that shared_preload_libraries is > a PITA. True. I don't really see that as a big deal. We can expect that most people will register tranches at startup, and the names will be available. If they don't, then the tranche name will have to be listed as something like extension, or maybe extension-tranche-123. I'm not prepared to revoke the ability to create tranches later for the convenience of this mechanism; the reporting mechanism has to adapt itself to what the code can support, not the other way around. Actually, I think it might very well be a good idea to fold all non-core tranches together under "extension" anyway for wait reporting purposes. The reason is that we are debating whether to report the wait event information as 1 byte or 4 bytes. The tranche ID by itself is 4 bytes, and lwlocks are not the only kind of wait event we need to be able to report. Unless we're prepared to make the wait-reporting stuff use more than 4 bytes, and therefore require a locking protocol (which I'm not keen about for reasons discussed upthread), we're not going to be able to report the full range of values anyway. My proposal is to have about 50 possible wait events for lwlocks: one for each individual lwlock, one for each builtin tranche, and one for everything else. That easily fits in one byte with plenty of room left over for all of the other stuff I want to report. If we've got four bytes, it's even simpler. If users of this facility can't distinguish a wait on an lwlock created by extension A from a wait on an lwlock created by extension B, I don't really care. That's going to be a really, really rare case: how many extensions use lwlocks anyway? How many of them use them enough to cause significant contention? Yeah, it could happen, but not often. Something pretty simple, dumb, and cheap here still figures to offer a lot of benefit. In fact, probably *more* benefit than a more complex, more general system. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers