Re: [PATCH] Refactoring of LWLock tranches - Mailing list pgsql-hackers

On Tue, Sep 15, 2015 at 2:44 PM, andres@anarazel.de <andres@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