Re: Statement timeout

Well, multiple parse/bind/execute messages before a sync are definitely used by PgJDBC and nPgSQL for batching, and I just posted a patch for it for libpq. I wouldn't have considered it to simulate multi-statement simple-protocol queries, but I guess there are some parallels.

I am very surprised to find out that statement_timeout tracks the total time and isn't reset by a new statement, but I guess it makes sense - what, exactly, delimits a "query" in extended query mode? statement_timeout in simple-query mode starts at parse time and runs until the end of execute. In e.q.p. there might be only one parse, then a series of Bind and Execute messages, or there may be repeated Parse messages.

Personally I'd be fairly happy with statement-timeout applying per-message in the extended query protocol. That would mean that it behaves slightly differently, and a query with a long slow parse and bind phase followed by quick execution might fail to time out in the extended query protocol where it would time out as a simple query. It'd behave as if the query was PREPAREd then separately EXECUTEd in simple-query protocol. I'm not hugely bothered by that, but if it's really a concern I'd ideally like to add a new protocol message that resets the statement timeout counter, so the client can define what delimits a statement. Not practical in the near term.

For now I'd be OK with documenting this as a quirk/limitation of statement_timeout, that it applies to a whole extended-query-protocol batch.