Re: Idle In Transaction Session Timeout, revived

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, David Steele <david(at)pgmasters(dot)net>, 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 23:16:01
Message-ID: 28458.1454541361@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Joshua D. Drake" <jd(at)commandprompt(dot)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, and then we are
definitely wasting resources by letting it monopolize a backend. Not as
many resources as if the xact were still open, but waste none the less.

My design sketch wherein we do nothing to notify the client certainly
doesn't do anything to help the client wake up, either. So maybe it's
fine and we should just go forward with the kill-the-connection approach.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-02-04 00:02:57 Sanity checking for ./configure options?
Previous Message Thomas Munro 2016-02-03 23:12:14 Re: WIP: Detecting SSI conflicts before reporting constraint violations