Re: Cancelling idle in transaction state

<div dir="ltr"><div class="gmail_quote">On Fri, Jan 1, 2010 at 8:38 PM, Robert Haas <span dir="ltr"><<a
href="mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>></span>wrote:<br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Jan 1, 2010, at
6:48AM, Simon Riggs <simon@2ndQuadrant.com> w<div class="im"><br /><blockquote class="gmail_quote"
style="border-left:1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> We could either
endlesslyrepeat this<br /><br /> ERROR:  current transaction is aborted because of conflict with<br /> recovery,
commandsignored until end of transaction block<br /></blockquote><br /></div> +1 for this option.<div class="im"><br
/><br/><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex;
padding-left:1ex;"> I'm also not sure why we would want to single out Hot Standby to<br /> generate the reason "because
ofconflict with recovery" when no other<br /> ERROR source would generate such a reason.<br /></blockquote><br /></div>
Well,most times when the transaction is aborted, it's because you did something wrong.  Or at least, the failure is
associatedwith some particular statement.<br /><br /> 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
suchcases.<br /><font color="#888888"> </font><br /></blockquote></div><br />Why not do the finger pointing (to HS) in
theDETAIL field of the ERROR, and let the error message remain the same.<br /><br />Best regards,<br />-- <br
/>gurjeet.singh<br/>@ EnterpriseDB - The Enterprise Postgres Company<br /><a
href="http://www.enterprisedb.com">http://www.enterprisedb.com</a><br/><br />singh.gurjeet@{ gmail | yahoo }.com<br
/>Twitter/Skype:singh_gurjeet<br /><br />Mail sent from my BlackLaptop device<br /></div>