Re: IDLE in transaction introspection

On Tue, Nov 1, 2011 at 8:41 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Tue, Nov 1, 2011 at 13:19, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> On Mon, Oct 31, 2011 at 10: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.
>>
>> Why not leave it exactly as it is, and add a previous_query column?
>>
>> That gives you exactly what you need without breaking anything.
>
> That would be the backwards compatible way I suggested.
>
> That said, I think there's still value in exposing a "state" column,
> and to encourage people not to rely on the text in the query column.
> Then you can add it to your list of things to remove in 10.0 :-)

Personally, I think we're getting a bit overexcited about backward
compatibility here. We make backward-incompatible changes in every
release. Things that change the behavior of user queries (like
reserving keywords, or other changes in syntax, or having the same
syntax now mean something different) cause a fair amount of user pain,
and we're justifiably cautious about making them. But changes that
have to do with server administration, as far as I can see, result in
much less pain. Splitting the current_query field into query and
state is going to require only the most minimal adjustment to user
code, and anyone for whom it's really a problem can easily create
their own view that mimics the old behavior. On the flip side,
keeping both fields around is going to make the pg_stat_activity,
which is already extremely wide, even more difficult to read in a
window of any reasonable width, especially because the field we're
proposing to duplicate is the widest one by far. I also doubt very
much that it creates a meaningful migration path; most people will
just keep doing it the old way until it breaks, and even new users may
not realize that one column is nominally deprecated.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company