Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Date
Msg-id 20151104215504.GK3685@tamriel.snowman.net
Whole thread Raw
In response to Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  (Joe Conway <mail@joeconway.com>)
Responses Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions  (David Steele <david@pgmasters.net>)
List pgsql-hackers
* Joe Conway (mail@joeconway.com) wrote:
> On 11/04/2015 01:24 PM, Alvaro Herrera wrote:
> > I agree with Pavel.  Having a transaction timeout just does not make any
> > sense.  I can see absolutely no use for it.  An idle-in-transaction
> > timeout, on the other hand, is very useful.
>
> +1 -- agreed

I'm not sure of that.  I can certainly see a use for transaction
timeouts- after all, they hold locks and can be very disruptive in the
long run.  Further, there are cases where a transaction is normally very
fast and in a corner case it becomes extremely slow and disruptive to
the rest of the system.  In those cases, having a timeout for it is
valuable.

David (adding him to the CC) actually developed a utility specifically
to identify what transactions are blocking what others and to kill off
other processes if they were running for too long and blocking higher
priority processes.  It didn't matter, in that environment, if they were
idle-in-transaction or actively running.

David, please correct/confirm my recollection above.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions