Re: idle_in_transaction_timeout - Mailing list pgsql-hackers

From Vik Fearing
Subject Re: idle_in_transaction_timeout
Date
Msg-id 538E6E59.2020602@dalibo.com
Whole thread
In response to Re: idle_in_transaction_timeout  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-hackers
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?

Meh.

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.
-- 
Vik

pgsql-hackers by date:

Previous
From: Haribabu Kommi
Date:
Subject: Re: [BUGS] BUG #9652: inet types don't support min/max
Next
From: Robert Haas
Date:
Subject: Re: idle_in_transaction_timeout