Re: idle_in_transaction_timeout

On Wed, Jun 25, 2014 at 11:40 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

Hmm, so there's no reason a client, after sending one protocol
message, might not pause before sending the next protocol message?
That seems like a surprising argument. Someone couldn't Parse and
then wait before sending Bind and Execute, or Parse and Bind and then
wait before sending Execute?

> 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.

That's an especially good point if we think that this feature will be
enabled commonly or by default - but as Fujii Masao says, it might be
tricky to avoid. :-(

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company