Re: exposing wait events for non-backends (was: Tracking wait event for latches)
Craig Ringer <craig@2ndquadrant.com>
From: Craig Ringer <craig@2ndquadrant.com>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Kevin Grittner <kgrittn@gmail.com>, Andres Freund <andres@anarazel.de>, Alvaro Herrera <alvherre@2ndquadrant.com>,
Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Alexander Korotkov <a.korotkov@postgrespro.ru>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2016-12-13T01:45:41Z
Lists: pgsql-hackers
On 13 December 2016 at 09:13, Michael Paquier <michael.paquier@gmail.com> wrote: > On Tue, Dec 13, 2016 at 10:05 AM, Craig Ringer <craig@2ndquadrant.com> wrote: >> We should probably expose a proc_type or something, with types: >> >> * client_backend >> * bgworker >> * walsender >> * autovacuum >> * checkpointer >> * bgwriter > > A text field is adapted then, more than a single character. > >> for simpler filtering. >> >> I don't think existing user code is likely to get upset by more >> processes appearing in pg_stat_activity, and it'll be very handy. > > Indeed, for WAL senders now abusing of the query field is definitely > not consistent. Even if having this information is useful, adding such > a column would make sense. Still, one thing that is important to keep > with pg_stat_activity is the ability to count the number of > connections that are part of max_connections for monitoring purposes. > The docs definitely would need an example of such a query counting > only client_backend and WAL senders and tell users that this can be > used to count how many active connections there are. Good point. No need for a new field, since a non-null client_port should be sufficient. But definitely documented. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Show more processes in pg_stat_activity.
- fc70a4b0df38 10.0 landed