On Wed, Jan 20, 2016 at 6:39 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Jan 19, 2016 at 11:49 PM, Amit Kapila <amit.kapil...@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
extend_pg_stat_activity_v8.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
