From: | decibel <decibel(at)decibel(dot)org> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Tatsuhito Kasahara <kasahara(dot)tatsuhito(at)oss(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: display previous query string of idle-in-transaction |
Date: | 2009-05-12 15:37:10 |
Message-ID: | A90F3088-EC12-4802-BFC0-BE7BFEBA08F9@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mar 27, 2009, at 2:36 AM, Simon Riggs wrote:
> 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.
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.
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(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-05-12 16:43:32 | pgsql: Fix LOCK TABLE to eliminate the race condition that could make it |
Previous Message | Tom Lane | 2009-05-12 14:58:12 | Re: Show method of index |