Re: RFC: replace pg_stat_activity.waiting with something more descriptive - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date
Msg-id CAA4eK1JHranT6uyS29EjmozMHxJrY699CMGKL89sYBcxf12f1A@mail.gmail.com
Whole thread Raw
In response to Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: RFC: replace pg_stat_activity.waiting with something more descriptive  ("andres@anarazel.de" <andres@anarazel.de>)
List pgsql-hackers
On Wed, Jan 20, 2016 at 6:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jan 19, 2016 at 11:49 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >> On the topic of the UI, I understand that redefining
> >> pg_stat_activity.waiting might cause some short-term annoyance.  But I
> >> think in the long term what we are proposing here is going to be a
> >> huge improvement, so I think it's worth the compatibility break.  If
> >> we say that pg_stat_activity.waiting has to continue meaning "waiting
> >> for a heavyweight lock" even though we now also expose (in some other
> >> location) information on other kinds of waits, that's going to be
> >> confusing to users.
> >
> > If we want to go via this route, then the first thing which we need to
> > decide is whether we want to start displaying the information of
> > background processes like WALWriter and others in pg_stat_activity?
>
> That doesn't seem like a particularly good fit - few of the fields are
> relevant to that case.  We could provide some other way of getting at
> the information for background processes if people want, but
> personally I'd probably be inclined not to bother with it for right
> now.
>

I have updated the patch accordingly.  pg_stat_get_activity.waiting is
changed to a text column wait_event and currently it will display the
heavy-weight and light-weight lock information for backends, certainly
it can be extended to report network wait or disk wait events, but I feel
that can be done as an add-on patch.  For LWLocks, it returns LWLock
name for individual locks and tranche name for others.



With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Attachment

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: PL/Pythonu - function ereport
Next
From: "andres@anarazel.de"
Date:
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive