Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Provide much better wait information in pg_stat_activity.
Date: 2016-03-12 07:24:15
Message-ID: CAA4eK1+gaV3D=Y+ecHgAm42o7LbcqfwtNMKeD5xDYm7G2bpjKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Sat, Mar 12, 2016 at 5:01 AM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
>
> On 3/10/16 8:36 PM, Robert Haas wrote:
>>
>> 1. We make it true only for heavyweight lock waits, and false for
>> other kinds of waits. That's pretty strange.
>> 2. We make it true for all kinds of waits that we now know how to
>> report. That still breaks compatibility.
>
>
> I would absolutely vote for 2 here. You could even argue that it's a bug
fix, since those were waits we technically should have been indicating.
>

I see it as reverse. I think waiting=true for only heavyweight locks makes
sense in existing versions as user can still find whats actually going in
the system either by looking at "query" in pg_stat_activity or by referring
pg_locks, but OTOH if waiting is true for all kind of waits (lwlock,
heavyweight lock, I/O, etc) then I think it will be difficult for user to
make any sense out of it. So I see going for option 2 can confuse users
rather than simplifying anything.

>
> Another random thought... changes like this would probably be easier to
handle if we provided backwards compatibility extensions that created views
> that mimicked the catalog for a specific Postgres version.
>

That makes sense to me if other people agree to it, but I think there will
be some maintenance overhead for it, but I see that as worth the effort in
terms of user convenience.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-03-12 15:33:54 Re: pgsql: Allow to trigger kernel writeback after a configurable number of
Previous Message Andres Freund 2016-03-12 06:08:32 Re: pgsql: Allow to trigger kernel writeback after a configurable number of

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2016-03-12 07:40:53 memory leak in GIN
Previous Message Salvador Fandiño 2016-03-12 07:22:30 Re: Perl's newSViv() versus 64-bit ints?