> 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)
Check. >> 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. It's too late. Someone has already moved the patch to the next CF (for PostgreSQL 11). >> 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
