On Jan 1, 2010, at 9:42 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
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.
Interesting. It's not obvious to me how killing an *idle* session can
resolve a deadlock. AIUI a deadlock requires a cycle in the waits-for
graph, and an idle transaction is not waiting for a lock acquisition.
I can see how it could be useful in handling serialization failures,
though, and there may be other applications as well. This is a nice
improvement; I'm pleased to see it going in.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
