From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Tatsuo Ishii > Actually the statement timer is replaced with new statement timer value > in enable_statement_timeout().
The patch doesn't seem to behave like that. The Parse message calls start_xact_command() -> enable_statement_timeout() -> enable_timeout(), and set stmt_timer_started to true. Subsequent Bind and Execute messages call enable_statement_timeout(), but enable_statement_timeout() doesn't call enable_timeout() because stmt_timer_started is already true. > > 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 I ran one INSERT statement using JDBC with log_min_messages = DEBUG3, and the server log shows what I said. DEBUG: parse <unnamed>: insert into a values(2) DEBUG: Set statement timeout LOG: duration: 0.431 ms parse <unnamed>: insert into a values(2) DEBUG: bind <unnamed> to <unnamed> LOG: duration: 0.127 ms bind <unnamed>: insert into a values(2) DEBUG: Disable statement timeout LOG: duration: 0.184 ms execute <unnamed>: insert into a values(2) DEBUG: snapshot of 1+0 running transaction ids (lsn 0/163BF28 oldest xid 561 latest complete 560 next xid 562) > 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 It works. The first Parse-Bind-Execute is measured as one unit, then subsequent Bind-Execute pairs are measured as other units. That's because each Execute ends the statement_timeout timer and the Bind message starts it again. I think this is desirable, so the current patch looks good. May I mark this as ready for committer? FYI, make check-world passed successfully. > Also what would happen if client just send a parse message and does nothing > after that? It's correct to trigger the statement timeout in this case, because the first SQL statement started (with the Parse message) and its execution is not finished (with Execute message.) Regards Takayuki Tsunakawa -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
