From: | Tatsuhito Kasahara <kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: display previous query string of idle-in-transaction |
Date: | 2009-03-30 07:08:07 |
Message-ID: | 49D06FD7.7030906@oss.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(Sorry for delay..)
Guillaume Smet wrote:
> 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.
Yes, I won't be able to *completely* detect which application is running
long transaction with a last query.
But, as I said, I can get a hint for guessing causes from it.
And, as Simon said, I can detect a problem point with collaboration
from other information (app's log, app's source, operation procedure, and so on).
> So, in fact, I'm still not convinced. Could you detail a bit more how
> you plan to use it?
Well, Now, I can't get enough information from pg_stat_activity.
So, I have to check huge logs or reproduce the same problem.
(They are annoying works.)
If I can check last and more queries, I can use it as a hint for narrowing
down problem points with app's log and so on.
# And search the point and fix (or suggesting action) it.
I hope it would be able to narrowing down problem points more easily.
Best regards,
--
Tatsuhito Kasahara
kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-03-30 08:34:31 | Re: New shapshot RPMs (Mar 27, 2009) are ready for testing |
Previous Message | Thomas Kellerer | 2009-03-30 06:56:12 | Re: New shapshot RPMs (Mar 27, 2009) are ready for testing |