Re: display previous query string of idle-in-transaction
От | Asko Oja |
---|---|
Тема | Re: display previous query string of idle-in-transaction |
Дата | |
Msg-id | ecd779860905122156o48b3d07al75d2d21751c2a5bd@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: display previous query string of idle-in-transaction (decibel <decibel@decibel.org>) |
Ответы |
Re: display previous query string of idle-in-transaction
|
Список | pgsql-hackers |
After taking look at our monitoring system i think some hint about previous SQL might be useful.
dba db70 db_name WARNING 1 long transactions, duration > 2690min user=postgres pid=7887 waiting=False query=<IDLE> in transaction
Currently i have no idea what exactly did i kill without digging in logs which might have rotated anyway by now.
regards,
Asko
dba db70 db_name WARNING 1 long transactions, duration > 2690min user=postgres pid=7887 waiting=False query=<IDLE> in transaction
Currently i have no idea what exactly did i kill without digging in logs which might have rotated anyway by now.
regards,
Asko
On Tue, May 12, 2009 at 6:37 PM, decibel <decibel@decibel.org> wrote:
On Mar 27, 2009, at 2:36 AM, Simon Riggs wrote:I have to distinct problems with idle in transaction. One is reporting users / the tools they're using. I'll often find transactions that have been open for minutes or hours. But, that's not a big deal for me, because that's only impacting londiste slaves, and I have no problem just killing those backends.Not really. I want to understand the actual problem with
idle-in-transaction so we can consider all ways to solve it, rather than
just focus on one method.
What does concern me is seeing idle in transaction from our web servers that lasts anything more than a few fractions of a second. Those cases worry me because I have to wonder if that's happening due to bad code. Right now I can't think of any way to figure out if that's the case other than a lot of complex logfile processing (assuming that would even work). But if I knew what the previous query was, I'd at least have half a chance to know what portion of the code was responsible, and could then look at the code to see if the idle state was expected or not.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: