Re: Statement timeout behavior in extended queries

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Tatsuo Ishii' <ishii@sraoss.co.jp>
Cc: "andres@anarazel.de" <andres@anarazel.de>, "david@fetter.org" <david@fetter.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-04-05T07:03:02Z
Lists: pgsql-hackers
From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tatsuo Ishii
> Since pgproto is a dumb protocol machine, it does not start a transaction
> automatically (user needs to explicitly send a start transaction command
> via either simple or extended query). In this particular case no explicit
> transaction has started.
> 

Then, the following sequence should have occurred.  The test result is valid.

# Execute statement which takes 2 seconds.
'P'	"S1"	"SELECT pg_sleep(2)"	0
  -> start transaction T1
'B'	"S2"	"S1"	0	0	0

'P'	""	"SET statement_timeout = '1s'"	0
'B'	""	""	0	0	0
'E'	""	0

# Execute statement which takes 2 seconds (statement timeout expected).
'E'	"S2"	0
  -> timeout error occurred, T1 aborted

# Issue Sync message
'S'
  -> rolled back T1, so statement_timeout reverted to 3s

# Receive response from backend
'Y'

# Execute statement which takes 2 seconds (statement timeout expected).
'P'	"S3"	"SELECT pg_sleep(2)"	0
  -> start transaction T2
'B'	"S2"	"S3"	0	0	0
'E'	"S2"	0

# Issue Sync message
'S'
  -> committed T2

Regards
Takayuki Tsunakawa



Commits

  1. Rearm statement_timeout after each executed query.