Re: display previous query string of idle-in-transaction - Mailing list pgsql-hackers

From Guillaume Smet
Subject Re: display previous query string of idle-in-transaction
Date
Msg-id 1d4e0c10903270038s1785d37ai80b82e70f3287a24@mail.gmail.com
Whole thread Raw
In response to Re: display previous query string of idle-in-transaction  (Guillaume Smet <guillaume.smet@gmail.com>)
Responses Re: display previous query string of idle-in-transaction  (Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>)
List pgsql-hackers
On Fri, Mar 27, 2009 at 8:27 AM, Guillaume Smet
<guillaume.smet@gmail.com> wrote:
> 2009/3/27 Tatsuhito Kasahara <kasahara.tatsuhito@oss.ntt.co.jp>:
>> But if I can also check last query string, I guess which apllication
>> do that and point out the problem point.
>
> Oh, I just understand why you want this patch. I usually have one
> database per server so I didn't see your point.

Thinking a bit more about it: the datname column in the
pg_stat_activity view gives you the database concerned and usename the
user used. So I still don't see your point: you can use different user
to distinguish the applications.

Moreover, if you're using connection pooling (which is more and more
common) and the same user for connecting to the database, you won't be
able to know if it's really the last query which causes the problem
(from my experience, it's usually not).

Being able to detect which application is running which query on the
very same database with the very same user seems like something not so
obvious and the use case seems to be pretty narrow. And IMHO, even if
we suppose you can make the difference between the applications with
only one query, you won't be able to limit your investigation to this
application.

So, in fact, I'm still not convinced. Could you detail a bit more how
you plan to use it?

-- 
Guillaume


pgsql-hackers by date:

Previous
From: Guillaume Smet
Date:
Subject: Re: New trigger option of pg_standby
Next
From: Greg Stark
Date:
Subject: Re: SSL over Unix-domain sockets