Re: Statement timeout behavior in extended queries

From: Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>
To: tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com
Cc: andres(at)anarazel(dot)de, david(at)fetter(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Statement timeout behavior in extended queries
Date: 2017-04-05 07:18:07
Message-ID: 20170405.161807.789558256920454554.t-ishii@sraoss.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Yes, I remembered that and was about to make a posting :-)

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

Yes, an extended query automatically starts a transaction if there's
no ongoing transaction.

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

Right. The automatically started transaction is aborted and the effect
of the set statement is canceled.

In summary, as far as I know Andres's patch is working as expected.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2017-04-05 07:28:50 Re: Adding support for Default partition in partitioning
Previous Message Andres Freund 2017-04-05 07:16:25 Re: Re: Query fails when SRFs are part of FROM clause (Commit id: 69f4b9c85f)