Re: display previous query string of idle-in-transaction

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

In response to

Responses

Browse pgsql-hackers by date

  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