Re: RFC: replace pg_stat_activity.waiting with something more descriptive
От | Robert Haas |
---|---|
Тема | Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Дата | |
Msg-id | CA+TgmoZVbhOxqKeS1pRxcHvW=isCx8Vymm3otpQMJ0L1nGoXYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: RFC: replace pg_stat_activity.waiting with something more descriptive (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: RFC: replace pg_stat_activity.waiting with something
more descriptive
Re: RFC: replace pg_stat_activity.waiting with something more descriptive Re: RFC: replace pg_stat_activity.waiting with something more descriptive |
Список | pgsql-hackers |
On Thu, Jun 25, 2015 at 9:23 AM, Peter Eisentraut <peter_e@gmx.net> wrote: > On 6/22/15 1:37 PM, Robert Haas wrote: >> Currently, the only time we report a process as waiting is when it is >> waiting for a heavyweight lock. I'd like to make that somewhat more >> fine-grained, by reporting the type of heavyweight lock it's awaiting >> (relation, relation extension, transaction, etc.). Also, I'd like to >> report when we're waiting for a lwlock, and report either the specific >> fixed lwlock for which we are waiting, or else the type of lock (lock >> manager lock, buffer content lock, etc.) for locks of which there is >> more than one. I'm less sure about this next part, but I think we >> might also want to report ourselves as waiting when we are doing an OS >> read or an OS write, because it's pretty common for people to think >> that a PostgreSQL bug is to blame when in fact it's the operating >> system that isn't servicing our I/O requests very quickly. > > Could that also cover waiting on network? Possibly. My approach requires that the number of wait states be kept relatively small, ideally fitting in a single byte. And it also requires that we insert pgstat_report_waiting() calls around the thing that is notionally blocking. So, if there are a small number of places in the code where we do network I/O, we could stick those calls around those places, and this would work just fine. But if a foreign data wrapper, or any other piece of code, does network I/O - or any other blocking operation - without calling pgstat_report_waiting(), we just won't know about it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: