Robert Haas <robertmh...@gmail.com> wrote: > 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. :-( I think that this patch, as it stands, is a clear win if the postgres_fdw part is excluded. Remaining points of disagreement seem to be the postgres_fdw, whether a default value measured in days might be better than a default of off, and whether it's worth the extra work of covering more. The preponderance of opinion seems to be in favor of excluding the postgres_fdw changes, with Tom being violently opposed to including it. I consider the idea of the FDW ignoring the server setting dead. Expanding the protected area of code seems like it would be sane to ask whoever wants to extend the protection in that direction to propose a patch. My sense is that there is more support for a default of a small number of days than a default of never, but that seems far from settled. I propose to push this as it stands except for the postgres_fdw part. The default is easy enough to change if we reach consensus, and expanding the scope can be a new patch in a new CF. Objections? -- Kevin Grittner EDB: 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
