From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | David Steele <david(at)pgmasters(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Vik Fearing <vik(at)2ndquadrant(dot)fr>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Idle In Transaction Session Timeout, revived |
Date: | 2016-02-03 22:36:18 |
Message-ID: | 56B280E2.2090203@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2/3/16 4:05 PM, David Steele wrote:
> On 2/3/16 4:25 PM, Tom Lane wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:
>>>> Wouldn't it be more sensible to just roll the transaction back and not
>>>> disconnect?
>>
>> I'm not sure how messy this would be in practice. But if we think that
>> killing the whole session is not desirable but something we're doing for
>> expediency, then it would be worth looking into that approach.
>
> 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.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2016-02-03 22:51:44 | Re: Idle In Transaction Session Timeout, revived |
Previous Message | David Steele | 2016-02-03 22:05:44 | Re: Idle In Transaction Session Timeout, revived |