From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: idle_in_transaction_timeout |
Date: | 2014-06-25 15:40:47 |
Message-ID: | 75706.1403710847@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> 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?
I think you just moved the goalposts to the next county.
The point of this feature, AFAICS, is to detect clients that are failing
to issue another query or close their transaction as a result of bad
client logic. It's not to protect against network glitches.
Moreover, there would be no way to implement a timeout like that without
adding a gettimeofday() call after every packet receipt, which is overhead
we do not need and cannot afford. I don't think this feature should add
*any* gettimeofday's beyond the ones that are already there.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-06-25 15:44:57 | Re: RLS Design |
Previous Message | Tom Lane | 2014-06-25 15:31:37 | Re: pg_filedump for 9.4? |