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 On Tue, May 12, 2009 at 6:37 PM, decibel <deci...@decibel.org> wrote: > 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 deci...@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 >
