On Jan 1, 2010, at 8:30 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
On Fri, 2010-01-01 at 07:08 -0800, Robert Haas wrote:
On Jan 1, 2010, at 6:48 AM, Simon Riggs <si...@2ndquadrant.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..
Hmm. I don't think I can get a serialization failure, deadlock, or out
of memory error while my session is idle. An idle timeout or SIGINT is
analagous, I think.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
