Re: idle_in_transaction_timeout - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: idle_in_transaction_timeout
Date
Msg-id CAHGQGwFnw3KEn5yjQE6Emj-tzuhE9AQit2vtBvdgOW=anJ1xRg@mail.gmail.com
Whole thread Raw
In response to Re: idle_in_transaction_timeout  (Vik Fearing <vik.fearing@dalibo.com>)
Responses Re: idle_in_transaction_timeout  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Jun 22, 2014 at 6:54 AM, Vik Fearing <vik.fearing@dalibo.com> wrote:
> On 06/21/2014 08:23 PM, Kevin Grittner wrote:
>> OK, so I think we want to see a patch based on v1 (FATAL approach)
>> with a change of the name to idle_in_transaction_session_timeout
>> and the units changed to milliseconds.  I don't see why the
>> remoteversion test shouldn't be changed to use 90500 now, too.
>
> The attached patch, rebased to current master, addresses all of these
> issues.

Sorry if this has already been discussed before....

Why is IIT timeout turned on only when send_ready_for_query is true?
I was thinking it should be turned on every time a message is received.
Imagine the case where the session is in idle-in-transaction state and
a client gets stuck after sending Parse message and before sending Bind
message. This case would also cause long transaction problem and should
be resolved by IIT timeout. But IIT timeout that this patch adds cannot
handle this case because it's enabled only when send_ready_for_query is
true. Thought?

Regards,

-- 
Fujii Masao



pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: Cluster name in ps output
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pg_resetxlog to clear backup start/end locations.