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
-
Rearm statement_timeout after each executed query.
- f8e5f156b30e 11.0 landed