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+TgmoZ5RDQCE01JJxnysqM5YaZ5W-pS1zz1__2CxQ-S3+QbBg@mail.gmail.com
Whole thread Raw
In response to Re: Idle In Transaction Session Timeout, revived  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Idle In Transaction Session Timeout, revived
List pgsql-hackers
On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 2/3/16 2:30 PM, Robert Haas wrote:
>>
>> On Sun, Jan 31, 2016 at 8:33 AM, Vik Fearing <vik@2ndquadrant.fr> wrote:
>>>
>>> Attached is a rebased and revised version of my
>>> idle_in_transaction_session_timeout patch from last year.
>>>
>>> This version does not suffer the problems the old one did where it would
>>> jump out of SSL code thanks to Andres' patch in commit
>>> 4f85fde8eb860f263384fffdca660e16e77c7f76.
>>>
>>> The basic idea is if a session remains idle in a transaction for longer
>>> than the configured time, that connection will be dropped thus releasing
>>> the connection slot and any locks that may have been held by the broken
>>> client.
>>>
>>> Added to the March commitfest.
>>
>>
>> +1 for doing something like this.  Great idea!
>
>
> Wouldn't it be more sensible to just roll the transaction back and not
> disconnect?

It would be nice to be able to do that, but the client-server protocol
can't handle it without losing sync.  Basically, if you send an error
to an idle client, you have to kill the session.  This has come up
many times before.

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



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Raising the checkpoint_timeout limit
Next
From: Robert Haas
Date:
Subject: Re: postgres_fdw join pushdown (was Re: Custom/Foreign-Join-APIs)