<div class="moz-cite-prefix">On 06/04/2014 02:01 AM, David G Johnston wrote:<br /></div><blockquote
cite="mid:CAKFQuwYwHkZXwt-NaUXsEP3XuSAunzbgPo8cbe_2Nv6M89hN1g@mail.gmail.com"type="cite"><div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Defaultto dropping the connection but give the usersadministrators the
capabilityto decide for themselves?</div></blockquote><br /> Meh.<br /><br /><blockquote
cite="mid:CAKFQuwYwHkZXwt-NaUXsEP3XuSAunzbgPo8cbe_2Nv6M89hN1g@mail.gmail.com"type="cite"><div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Istill haven't heard an argument for why this wouldn't apply to aborted
idle-in-transactions. I get the focus in on releasing locks but if the transaction fails but still hangs around forever
itis just as broken as one that doesn't fail and hangs around forever. <br /></div></blockquote><br /> My main concern
waswith locks and blocking VACUUM. Aborted transactions don't do either of those things. The correct solution is to
terminateaborted transaction, too, or not terminate anything and abort the idle ones.<br /><br /><blockquote
cite="mid:CAKFQuwYwHkZXwt-NaUXsEP3XuSAunzbgPo8cbe_2Nv6M89hN1g@mail.gmail.com"type="cite"><div class="gmail_default"
style="font-family:arial,helvetica,sans-serif">Evenif you limit the end result to only aborting the transaction the
end-userwill likely want to distinguish between their transaction failing and their failed transaction remaining idle
toolong - if only to avoid the situation where they make the transaction no longer fail but still hit the
timeout.</div></blockquote><br/> But hitting the timeout *is* failing.<br /><br /> With the new patch, the first query
willsay that the transaction was aborted due to timeout. Subsequent queries will do as they've always done.<br /><pre
class="moz-signature"cols="72">--
Vik</pre>