Re: RFC: replace pg_stat_activity.waiting with something more descriptive

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Дата
Msg-id CAPpHfdvDJzZDA8P7pxVFFKwv8995CjP5z10C8GgDM+Mtq10kAw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru>)
Ответы Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: RFC: replace pg_stat_activity.waiting with something more descriptive  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Thu, Aug 6, 2015 at 1:01 PM, Ildus Kurbangaliev <i.kurbangaliev@postgrespro.ru> wrote:
On 08/05/2015 09:33 PM, Robert Haas wrote:
On Wed, Aug 5, 2015 at 1:10 PM, Ildus Kurbangaliev
<i.kurbangaliev@postgrespro.ru> wrote:
About `memcpy`, PgBackendStatus struct already have a bunch of multi-byte
variables,  so it will be
not consistent anyway if somebody will want to copy it in that way. On the
other hand two bytes in this case
give less overhead because we can avoid the offset calculations. And as I've
mentioned before the class
of wait will be useful when monitoring of waits will be extended.
You're missing the point.  Those multi-byte fields have additional
synchronization requirements, as I explained in some detail in my
previous email. You can't just wave that away.
I see that now. Thank you for the point.

I've looked deeper and I found PgBackendStatus to be not a suitable
place for keeping information about low level waits. Really, PgBackendStatus
is used to track high level information about backend. This is why auxiliary
processes don't have PgBackendStatus, because they don't have such information
to expose. But when we come to the low level wait events then auxiliary
processes are as useful for monitoring as backends are. WAL writer,
checkpointer, bgwriter etc are using LWLocks as well. This is certainly unclear
why they can't be monitored.

This is why I think we shoudn't place wait event into PgBackendStatus. It
could be placed into PGPROC or even separate data structure with different
concurrency model which would be most suitable for monitoring.

+1 for tracking wait events not only for backends

Ildus, could you do following?
1) Extract LWLocks refactoring into separate patch.
2) Make a patch with storing current wait event information in PGPROC.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: why can the isolation tester handle only one waiting process?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: RFC: replace pg_stat_activity.waiting with something more descriptive