Re: Statement timeout behavior in extended queries
От | Tatsuo Ishii |
---|---|
Тема | Re: Statement timeout behavior in extended queries |
Дата | |
Msg-id | 20170404.122658.472182550318329721.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Statement timeout behavior in extended queries ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
Список | 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 eachmessage 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
В списке pgsql-hackers по дате отправления: