On Jan 1, 2010, at 9:42 AM, Simon Riggs <simon@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