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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RFC: replace pg_stat_activity.waiting with something more descriptive
Date: 2015-06-26 03:39:05
Message-ID: CA+TgmoZVbhOxqKeS1pRxcHvW=isCx8Vymm3otpQMJ0L1nGoXYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 25, 2015 at 9:23 AM, Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Brendan Jurd 2015-06-26 03:43:17 Re: [PATCH] Function to get size of asynchronous notification queue
Previous Message Robert Haas 2015-06-26 03:34:10 Re: RFC: replace pg_stat_activity.waiting with something more descriptive