| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Simon Riggs <simon(at)2ndQuadrant(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 15:08:04 |
| Message-ID: | E4EE6B9E-2E7A-414E-9112-6012EDE8BD79@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2010-01-01 15:14:20 | Re: Cancelling idle in transaction state |
| Previous Message | Magnus Hagander | 2010-01-01 14:57:59 | Re: krb_server_keyfile setting doesn't work on Windows |