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(dot)Nasby(at)bluetreble(dot)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.