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

From Tsunakawa, Takayuki
Subject Re: Statement timeout behavior in extended queries
Date
Msg-id 0A3221C70F24FB45833433255569204D1F6C0C16@G01JPEXMBYT05
Whole thread Raw
In response to Re: Statement timeout behavior in extended queries  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Responses Re: Statement timeout behavior in extended queries
List 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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: partitioned tables and contrib/sepgsql
Next
From: Kuntal Ghosh
Date:
Subject: Re: strange parallel query behavior after OOM crashes