From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@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
alreadytrue.
> > 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
otherunits. That's because each Execute ends the statement_timeout timer and the Bind message starts it again. I
thinkthis is desirable, so the current patch looks good. May I mark this as ready for committer? FYI, make
check-worldpassed 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
