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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Дата
Msg-id CAB7nPqQPWcFrCnNazwtOBTmVwDANRanB3iKo_dfY-eCu7bz_ig@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Craig Ringer <craig@2ndquadrant.com>)
Ответы Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Craig Ringer <craig@2ndquadrant.com>)
Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Proposal : Parallel Merge Join
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take