Re: IDLE in transaction introspection

From: Robert Treat <rob(at)xzilla(dot)net>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: IDLE in transaction introspection
Date: 2011-11-15 18:18:54
Message-ID: CABV9wwN-rhjCUUkgoTQjVKMWkrAQLNss9yR7YAWA8EwFTkMzfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 15, 2011 at 12:00 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> On 11/15/2011 09:44 AM, Scott Mead wrote:
>>
>> Fell off the map last week, here's v2 that:
>>  * RUNNING => active
>>  * all states from CAPS to lower case
>>
>
> This looks like what I was hoping someone would add here now.  Patch looks
> good, only issue I noticed was a spaces instead of a tab goof where you set
> beentry_>st_state at line 2419 in src/backend/postmaster/pgstat.c
>
> Missing pieces:
>
> -There is one regression test that uses pg_stat_activity that is broken now.
> -The documentation should list the new field and all of the states it might
> include.  That's a serious doc update from the minimal info available right
> now.
>
> I know this issue has been beat up already some, but let me summarize and
> extend that thinking a moment.  I see two equally valid schools of thought
> on how exactly to deal with introducing this change:
>
> -Add the new state field just as you've done it, but keep updating the query
> text anyway.  Do not rename current_query.  Declare the overloading of
> current_query as both a state and the query text to be deprecated in 9.3.
>  This would keep existing tools working fine against 9.2 and give a clean
> transition period.
>
> -Forget about backward compatibility and just put all the breaking stuff
> we've been meaning to do in here.  If we're going to rename current_query to
> query--what Scott's patch does here--that will force all code using
> pg_stat_activity to be rewritten.  This seems like the perfect time to also
> change "procpid" to "pid", finally blow away that wart.
>

+1

> I'll happily update all of the tools and samples I deal with to support this
> change.  Most of the ones I can think of will be simplified; they're already
> parsing query_text and extracting the implicit state.  Just operating on an
> explicit one instead will be simpler and more robust.
>

lmk if you need help, we'll be doing this with some of our tools /
projects anyway, it probably wouldn't hurt to coordinate.

Robert Treat
conjecture: xzilla.net
consulting: omniti.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-11-15 18:19:11 Re: Core Extensions relocation
Previous Message Robert Haas 2011-11-15 18:03:03 Re: Core Extensions relocation