Last week I noticed that the Wait Event/Locks system doesn't correctly describe waits for tuple locks because in some cases that happens in two stages.
Now I notice that the Wait Event system doesn't handle waiting for recovery conflicts at all, though it does access ProcArrayLock multiple times. In both cases I tried to fix the problem before mentioning it here. We can't add waits for either of those in a simple way because the current system doesn't allow us to report multiple levels of wait. In both these cases there is a single "top level wait" i.e. tuple locking or recovery conflicts, even if there are other waits that form part of the total wait. I'm guessing that there are other situations like this also. Don't have a concrete proposal, but I think we need a more complex model for how we record wait event data. Something that separates intention (e.g. "Travelling to St.Ives") from current event (e.g. "Waiting for LWLock") -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
