On 06/14/2011 11:44 AM, Jim Nasby wrote:
Wouldn't it be better still to have both the new and old columns
available for a while? That would produce the minimum amount of
disruption to tools, etc.
Doing this presumes the existence of a large number of tools where the
author is unlikely to be keeping up with PostgreSQL development. I
don't believe that theorized set of users actually exists. There are
people who use pg_stat_activity simply, and there are tool authors who
are heavily involved enough that they will see a change here coming far
enough in advance to adopt it without disruption. If there's a large
base of "casual" tool authors, who wrote something using
pg_stat_activity once and will never update it again, I don't know where
they are.
Anyway, I want a larger change to pg_stat_activity than this one, and I
would just roll fixing this column name into that more disruptive and
positive change. Right now the biggest problem with this view is that
you have to parse the text of the query to figure out what state the
connection is in. This is silly; there should be boolean values exposed
for "idle" and "in transaction". I want to be able to write things like
this:
SELECT idle,in_trans,count(*) FROM pg_stat_activity GROUP BY idle,in_trans;
SELECT min(backend_start) FROM pg_stat_activity WHERE idle;
Right now the standard approach to this is to turn current_query into a
derived state value using CASE statements. It's quite unfriendly, and a
bigger problem than this procpid mismatch. Fix that whole mess at once,
and now you've got something useful enough to justify breaking tools.
--
Greg Smith 2ndQuadrant US g...@2ndquadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
