Request a Demo
Home   >   mailing lists

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

From Gurjeet Singh
Subject Re: Cancelling idle in transaction state
Date
Msg-id 65937bea1001010827x30777895w463ebcf38706e945@mail.gmail.com
Whole thread Raw
In response to Re: Cancelling idle in transaction state  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Tree view
On Fri, Jan 1, 2010 at 8:38 PM, Robert Haas <robertmhaas@gmail.com> wrote:
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.


Why not do the finger pointing (to HS) in the DETAIL field of the ERROR, and let the error message remain the same.

Best regards,
--
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.enterprisedb.com

singh.gurjeet@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Change to config.pl processing in the msvc build environment
Next
From: Simon Riggs
Date:
Subject: Re: Cancelling idle in transaction state