| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Joachim Wieland <joe(at)mcknight(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, James Pye <lists(at)jwp(dot)name>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cancelling idle in transaction state |
| Date: | 2010-01-01 17:42:44 |
| Message-ID: | 1262367764.19367.16107.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-01-01 17:47:49 | Re: Win64 warnings about size_t |
| Previous Message | Simon Riggs | 2010-01-01 17:35:49 | Re: Cancelling idle in transaction state |