On Thu, Jan 28, 2016 at 2:12 AM, Robert Haas <robertmh...@gmail.com> wrote:
>
> On Tue, Jan 26, 2016 at 3:10 AM, and...@anarazel.de <and...@anarazel.de>
wrote:
> > I do think there's a considerable benefit in improving the
> > instrumentation here, but his strikes me as making live more complex for
> > more users than it makes it easier. At the very least this should be
> > split into two fields (type & what we're actually waiting on). I also
> > strongly suspect we shouldn't use in band signaling ("process not
> > waiting"), but rather make the field NULL if we're not waiting on
> > anything.
>
> +1 for splitting it into two fields.
>I will take care of this. > > Regarding making the field NULL, someone (I think you) proposed > previously that we should have one field indicating whether we are > waiting, and a separate field (or two) indicating the current or most > recent wait event. > I think to do that way we need to change the meaning of pg_stat_activity. waiting from waiting on locks to waiting on HWLocks and LWLocks and other events which we add in future. That can be again other source of confusion where if existing users of pg_stat_activity.waiting are still relying on it, they can get wrong information or if they are aware of the recent change, then they need to add additional check like (waiting = true && wait_event_type = 'HWLock')). So I think it is better to go with suggestion where we can display NULL in the new field when there is no-wait. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
