Re: Nested Wait Events?

On Mon, Dec 12, 2016 at 11:33 AM, Simon Riggs <simon(at)2ndquadrant(dot)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