On 2015-06-25 16:07:45 +0530, Amit Kapila wrote:
> On Tue, Jun 23, 2015 at 2:33 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> > If people feel strongly about backward compatibility, yes, we can do
> > that. However, if waiting continues to mean "on a heavyweight lock"
> > for backward compatibility, then you could sometimes have waiting =
> > false but wait_state non-null. That seems confusing enough to be a
> > bad plan, at least to me.
> >
>
> That's right if we leave the 'waiting' as it is for the sake of backward
> compatibility, then it will be confusing after we add wait_event to
> pg_stat_activity and if we change it such that for any kind of wait_event
> waiting will be true (or entirely remove waiting), then it will break the
> backward compatibility. So we have below alternatives here:
> 1. Remove/Change 'waiting' in pg_stat_activity and break the backward
> compatibility. I think we should try to avoid going via this route.
>
> 2. Add 2 new columns to pg_stat_activity
> waiting_resource - true for waits other heavy wait locks, false
> otherwise
> wait_event - description code for the wait event
>
> 3. Add new view 'pg_stat_wait_event' with following info:
> pid - process id of this backend
> waiting - true for any form of wait, false otherwise
> wait_event_type - Heavy Weight Lock, Light Weight Lock, I/O wait, etc
> wait_event - Lock (Relation), Lock (Relation Extension), etc
>
> Do you think 2nd or 3rd could be viable way to proceed for this feature?
3) sounds best to me. Keeping 'waiting' even makes sense in that case,
because it'll tell whether wait_event_type is currently being blocked
on. We can leave the former contents in until the next thing is being
blocked...
Greetings,
Andres Freund
