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

  1. Rearm statement_timeout after each executed query.