Re: Idle In Transaction Session Timeout, revived

On 02/03/2016 02:52 PM, Robert Haas wrote:
> On Wed, Feb 3, 2016 at 5:36 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>>> I think killing the session is a perfectly sensible thing to do in this
>>> case.  Everything meaningful that was done in the session will be rolled
>>> back - no need to waste resources keeping the connection open.
>>
>>
>> Except you end up losing stuff like every GUC you've set, existing temp
>> tables, etc. For an application that presumably doesn't matter, but for a
>> user connection it would be a PITA.
>>
>> I wouldn't put a bunch of effort into it though. Dropping the connection is
>> certainly better than nothing.
>
> 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 can see 
doing what connection poolers do (DISCARD ALL) + a rollback but the idea 
that we are going to destroy a connection to the database due to an idle 
transaction seems like a potential foot gun. Unfortunately, outside of a 
feeling I can not provide a good example.

Sincerely,

JD



-- 
Command Prompt, Inc.                  http://the.postgres.company/                        +1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.