On Tue, Nov 1, 2011 at 00:18, Scott Mead <scottm@openscg.com> wrote:
>
>
> On Mon, Oct 31, 2011 at 6:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Mon, Oct 31, 2011 at 5:45 PM, Magnus Hagander <magnus@hagander.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 )
If we're going with breaking compatibility, "waiting" should be a
state as well, I think. Actually, it should be even if we're not
breaking compatibilty, but just adding a state field.
> '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 :)
I think the question is how Ok it is to break compatibility. We could
always leave current_query in there and create a new field for
last_query *and* introduce a state... And then advertise a change in
the future. But that might be too much...
If we are doing it, it might be useful to just call it "query", so
that it is dead obvious to people that the definition changed..
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
