Re: Statement timeout behavior in extended queries
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Tatsuo Ishii <ishii@sraoss.co.jp>, tsunakawa.takay@jp.fujitsu.com,
david@fetter.org, pgsql-hackers@postgresql.org
Date: 2017-04-05T04:39:51Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2017-04-05 10:05:19 +0900, Tatsuo Ishii wrote: >> What's your point of the question? What kind of problem do you expect >> if the timeout starts only once at the first parse meesage out of >> bunch of parse messages? > It's perfectly valid to send a lot of Parse messages without > interspersed Sync or Bind/Execute message. There'll be one timeout > covering all of those Parse messages, which can thus lead to a timeout, > even though nothing actually takes long individually. It might well be reasonable to redefine statement_timeout as limiting the total time from the first client input to the response to Sync ... but if that's what we're doing, let's make sure we do it consistently. I haven't read the patch, but the comments in this thread make me fear that it's introducing some ad-hoc, inconsistent behavior. regards, tom lane
Commits
-
Rearm statement_timeout after each executed query.
- f8e5f156b30e 11.0 landed