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

Reply via email to