Re: Cancelling idle in transaction state

Simon Riggs <simon@2ndquadrant.com>

From: Simon Riggs <simon@2ndQuadrant.com>

To: Robert Haas <robertmhaas@gmail.com>

Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Joachim Wieland <joe@mcknight.de>, Tom Lane <tgl@sss.pgh.pa.us>, Hannu Krosing <hannu@2ndquadrant.com>, James Pye <lists@jwp.name>, pgsql-hackers <pgsql-hackers@postgresql.org>

Date: 2010-01-01T17:42:44Z

Lists: pgsql-hackers

On Fri, 2010-01-01 at 09:24 -0800, Robert Haas wrote:

> >> If we have other events that can asynchronously roll back a
> >> transaction, I would think they would deserve similar handling.  Off
> >> the top of my head, I'm not sure if there are any such cases.
> >
> > Serialization failures, deadlocks, timeouts, SIGINT, out of memory
> > errors etc..
> 
> Hmm. I don't think I can get a serialization failure, deadlock, or out  
> of memory error while my session is idle. 

Agreed. As a point of note, now that we can cancel idle transactions
there isn't any future blocker from making serialization failures or
deadlocks cancel such transactions... Other RDBMS have deadlock
detectors that can pick any session to resolve, not just the one doing
the deadlock checking.

> An idle timeout or SIGINT is analagous, I think.

-- 
 Simon Riggs           www.2ndQuadrant.com