Re: idle_in_transaction_timeout

From: Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>
To: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: idle_in_transaction_timeout
Date: 2014-06-04 00:54:49
Message-ID: 538E6E59.2020602@dalibo.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-04 02:28:19 Re: idle_in_transaction_timeout
Previous Message Haribabu Kommi 2014-06-04 00:37:48 Re: [BUGS] BUG #9652: inet types don't support min/max