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
