Re: Cancelling idle in transaction state - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Cancelling idle in transaction state
Date
Msg-id E4EE6B9E-2E7A-414E-9112-6012EDE8BD79@gmail.com
Whole thread Raw
In response to Re: Cancelling idle in transaction state  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Cancelling idle in transaction state  (Gurjeet Singh <singh.gurjeet@gmail.com>)
Re: Cancelling idle in transaction state  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Jan 1, 2010, at 6:48 AM, Simon Riggs <simon@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.

...Robert


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: krb_server_keyfile setting doesn't work on Windows
Next
From: Heikki Linnakangas
Date:
Subject: Re: Cancelling idle in transaction state