| 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 16:30:05 |
| Message-ID: | 1262363405.19367.15803.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
> On Jan 1, 2010, at 6:48 AM, Simon Riggs <simon(at)2ndQuadrant(dot)com> w
> > We could either endlessly repeat this
> >
> > ERROR: current transaction is aborted because of conflict with
> > recovery, commands ignored until end of transaction block
>
> +1 for this option.
>
> > I'm also not sure why we would want to single out Hot Standby to
> > generate the reason "because of conflict with recovery" when no other
> > ERROR source would generate such a reason.
>
> Well, most times when the transaction is aborted, it's because you did
> something wrong. Or at least, the failure is associated with some
> particular statement.
>
> 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..
--
Simon Riggs www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-01-01 17:21:02 | Re: about some parameters |
| Previous Message | Gurjeet Singh | 2010-01-01 16:27:43 | Re: Cancelling idle in transaction state |