On 06/04/2014 02:01 AM, David G Johnston wrote:
> Default to dropping the connection but give the usersadministrators
> the capability to decide for themselves?
> I still 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 it is just
> as broken as one that doesn't fail and hangs around forever.
My main concern was with locks and blocking VACUUM. Aborted
transactions don't do either of those things. The correct solution is
to terminate aborted transaction, too, or not terminate anything and
abort the idle ones.
> Even if you limit the end result to only aborting the transaction the
> end-user will likely want to distinguish between their transaction
> failing and their failed transaction remaining idle too long - if only
> to avoid the situation where they make the transaction no longer fail
> but still hit the timeout.
But hitting the timeout *is* failing.
With the new patch, the first query will say that the transaction was
aborted due to timeout. Subsequent queries will do as they've always done.