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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)
Дата
Msg-id CA+TgmoYH2sfgW1NqQLr+_9dK3e=BFR+dZLNv2JVV52xaJGg0xg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] exposing wait events for non-backends (was: Trackingwait event for latches)  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Mon, Dec 12, 2016 at 8:13 PM, 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.

Sure.

>> 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.

Let's confine ourselves to fixing one problem at a time.  I think we
can get where we want to be in this case by adding one new column and
some new rows to pg_stat_activity.  Michael, is that something you're
going to do?  If not, one of my esteemed colleagues here at
EnterpriseDB will have a try.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Declarative partitioning - another take
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: [HACKERS] [OSSTEST PATCH 0/1] PostgreSQL db: Retry on constraintviolation [and 2 more messages]