Re: Statement timeout behavior in extended queries - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Statement timeout behavior in extended queries
Date
Msg-id 20170404.143513.1852729952807165957.t-ishii@sraoss.co.jp
Whole thread Raw
Responses Re: Statement timeout behavior in extended queries  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
> 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
messagescall enable_statement_timeout(), but enable_statement_timeout() doesn't call enable_timeout() because
stmt_timer_startedis 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
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.
 

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
> 
> 
> 



pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Parallel Append implementation
Next
From: Ashutosh Bapat
Date:
Subject: Re: postgres_fdw bug in 9.6