On Mon, Dec 12, 2016 at 11:33 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > 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.
Well, I replied to that email to say that I didn't agree with your analysis. I think if something happens in two stages, those wait events should be distinguished. The whole point here is to get clarity on what the system is waiting for, and we lose that if we start trying to merge together things which are at the code level separate. > Now I notice that the Wait Event system doesn't handle waiting for > recovery conflicts at all, though it does access ProcArrayLock > multiple times. This isn't a very clear statement. Every place in the system that can provoke a wait on a latch or a process semaphore display some kind of wait event in pg_stat_activity. Some of those displays may not be as clear or detailed as you would like and that's fine, but saying they are not handled is not exactly true. > 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") That's not a bad thought. We need to be careful to keep this very lightweight so that it doesn't affect performance, but the general concept of separating intention from current event might have some legs. We just need to be careful that it doesn't involve into something that involves a lot of complicated bookkeeping, because these wait events can occur very frequently and in hot code-paths. -- 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