Re: Statement timeout behavior in extended queries
От | Tsunakawa, Takayuki |
---|---|
Тема | Re: Statement timeout behavior in extended queries |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1F6C0C16@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | Re: Statement timeout behavior in extended queries (Tatsuo Ishii <ishii@sraoss.co.jp>) |
Ответы |
Re: Statement timeout behavior in extended queries
|
Список | 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 по дате отправления: