Skip site navigation (1) Skip section navigation (2)

Re: IDLE in transaction introspection

From: Scott Mead <scottm(at)openscg(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: IDLE in transaction introspection
Date: 2011-10-31 23:18:42
Message-ID: CAKq0gvKUgN3mXKjCtSujtYiOtrH9D524PyY3f6mJ-0OC3=0Edg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Oct 31, 2011 at 7:18 PM, Scott Mead <scottm(at)openscg(dot)com> wrote:

>
>
> On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com>wrote:
>
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander <magnus(at)hagander(dot)net>
>> wrote:
>> > Actually, for the future, it might be useful to have a "state" column,
>> > that holds the idle/in transaction/running status, instead of the
>> > tools having to parse the query text to get that information...
>>
>> +1 for doing it this way.  Splitting "current_query" into "query" and
>> "state" would be more elegant and easier to use all around.
>>
>
> I'm all for splitting it out actually.  My concern was that I would break
> the 'ba-gillion' monitoring tools that already have support for
> pg_stat_activity if I dropped a column.  What if we had:
>
>    'state' :             idle | in transaction | running ( per Robert )
>

   Sorry per Robert and Jaime


>    'current_query' :  the most recent query (either last / currently
> running)
>
>    That may be a bit tougher to get across to people though (especially in
> the case where state='<IDLE>').
>
>  I'll rework this when I don't have trick-or-treaters coming to the front
> door :)
>
> --
>  Scott Mead
>   OpenSCG http://www.openscg.com
>
>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2011-11-01 04:22:47
Subject: Re: psql expanded auto
Previous:From: Scott MeadDate: 2011-10-31 23:18:07
Subject: Re: IDLE in transaction introspection

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group