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+TgmoZE1vBDQYetuJ_MPBw7YmEmygOE7KANo2ud5epLHH7LiQ@mail.gmail.com
Whole thread Raw
In response to Re: Idle In Transaction Session Timeout, revived  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Idle In Transaction Session Timeout, revived
Re: Idle In Transaction Session Timeout, revived
List pgsql-hackers
On Wed, Feb 3, 2016 at 6:16 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Joshua D. Drake" <jd@commandprompt.com> writes:
>> On 02/03/2016 02:52 PM, Robert Haas wrote:
>>> Well, my view is that if somebody wants an alternative behavior
>>> besides dropping the connection, they can write a patch to provide
>>> that as an additional option.  That, too, has been discussed before.
>>> But the fact that somebody might want that doesn't make this a bad or
>>> useless behavior.  Indeed, I'd venture that more people would want
>>> this than would want that.
>
>> Something feels wrong about just dropping the connection.
>
> I have the same uneasy feeling about it as JD.  However, you could
> certainly argue that if the client application has lost its marbles
> to the extent of allowing a transaction to time out, there's no good
> reason to suppose that it will wake up any time soon, ...

That's exactly what I think.  If you imagine a user who starts a
transaction and then leaves for lunch, aborting the transaction seems
nicer than killing the connection.  But what I think really happens is
some badly-written Java application loses track of a connection
someplace and just never finds it again.  Again, I'm not averse to
having both behavior someday, but my gut feeling is that killing the
connection will be the more useful one.

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



pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)
Next
From: Robert Haas
Date:
Subject: Re: CustomScan in a larger structure (RE: CustomScan support on readfuncs.c)