Re: Idle In Transaction Session Timeout, revived - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Idle In Transaction Session Timeout, revived
Date
Msg-id CA+TgmobZ7=piSU9a6+ru2cQWhGDoixJF2H-C5HV4T_auS+KqoQ@mail.gmail.com
Whole thread Raw
In response to Re: Idle In Transaction Session Timeout, revived  (Andres Freund <andres@anarazel.de>)
Responses Re: Idle In Transaction Session Timeout, revived
List pgsql-hackers
On Tue, Mar 8, 2016 at 6:08 PM, Andres Freund <andres@anarazel.de> wrote:
> On 2016-03-08 16:42:37 -0500, Robert Haas wrote:
>> - I really wonder if the decision to ignore sessions that are idle in
>> transaction (aborted) should revisited.  Consider this:
>>
>> rhaas=# begin;
>> BEGIN
>> rhaas=# lock table pg_class;
>> LOCK TABLE
>> rhaas=# savepoint a;
>> SAVEPOINT
>> rhaas=# select 1/0;
>> ERROR:  division by zero
>
> Probably only if the toplevel transaction is also aborted. Might not be
> entirely trivial to determine.

Yes, that would be one way to do it - or just ignore whether it's
aborted or not and make the timeout always apply.  That seems pretty
reasonable, too, because a transaction that's idle in transaction and
aborted could easily be one that the client has forgotten about, even
if it's not hanging onto any resources other than a connection slot.
And, if it turns out that the client didn't forget about it, well,
they don't lose anything by retrying the transaction on a new
connection anyway.

On a procedural note, I'm happy to push this patch through to commit
if it gets updated in the near future.  If not, we should mark it
Returned with Feedback and Vik can resubmit for 9.7.  Tempus fugit.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: [PATCH] fix DROP OPERATOR to reset links to itself on commutator and negator
Next
From: David Steele
Date:
Subject: Re: pg_hba_lookup function to get all matching pg_hba.conf entries