Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches) - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Date
Msg-id d0baf7ce-ae76-9c89-5c78-a04c0bf51156@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Kuntal Ghosh <kuntalghosh.2007@gmail.com>)
Responses Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Robert Haas <robertmhaas@gmail.com>)
Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Perhaps I'm confused by the title of this thread/CF entry, but
background workers already do show up in pg_stat_activity.  (You can
verify that by testing the background sessions patch.)  So which
additional things are we aiming to see with this?

In practice, I think it's common to do a quick select * from
pg_stat_activity to determine whether a database instance is in use.
(You always see your own session, but that's easy to eyeball.)  If we
add all the various background processes by default, that will make
things harder, especially if there is no straightforward way to filter
them out.

Perhaps a pg_stat_user_* and pg_stat_system_* split like we have for
some of the statistics tables would be useful?

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: [HACKERS] tzdata2017a breaks timestamptz regression test
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Documentation improvements for partitioning