On Wed, Jun 25, 2014 at 11:40 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Fujii Masao <masao.fu...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
