Re: Statement timeout behavior in extended queries
Tatsuo Ishii <ishii@sraoss.co.jp>
From: Tatsuo Ishii <ishii@sraoss.co.jp>
To: tsunakawa.takay@jp.fujitsu.com
Cc: ishii@sraoss.co.jp, david@fetter.org, pgsql-hackers@postgresql.org
Date: 2017-04-04T03:26:58Z
Lists: pgsql-hackers
> Where is the statement_timeout timer stopped when processing Parse and Bind messages? Actually the statement timer is replaced with new statement timer value in enable_statement_timeout(). > Do you mean the following sequence of operations are performed in this patch? > > Parse(statement1) > start timer > stop timer > Bind(statement1, portal1) > start timer > stop timer > Execute(portal1) > start timer > stop timer > Sync Yes. > It looks like the patch does the following. I think this is desirable, because starting and stopping the timer for each message may be costly as Tom said. > Parse(statement1) > start timer > Bind(statement1, portal1) > Execute(portal1) > stop timer > Sync This doesn't work in general use cases. Following pattern appears frequently in applications. Parse(statement1) Bind(statement1, portal1) Execute(portal1) Bind(statement1, portal1) Execute(portal1) : : Sync Also what would happen if client just send a parse message and does nothing after that? So I think following is better: Parse(statement1) Bind(statement1, portal1) Execute(portal1) start timer stop timer Bind(statement1, portal1) Execute(portal1) start timer stop timer : : Sync Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Commits
-
Rearm statement_timeout after each executed query.
- f8e5f156b30e 11.0 landed