Re: Statement timeout behavior in extended queries
Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Andres Freund' <andres@anarazel.de>
Cc: Tatsuo Ishii <ishii@sraoss.co.jp>, "david@fetter.org" <david@fetter.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-04-05T05:15:12Z
Lists: pgsql-hackers
From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of 'Andres Freund' > Attached. I did not like that the previous patch had the timeout handling > duplicated in the individual functions, I instead centralized it into > start_xact_command(). Given that it already activated the timeout in the > most common cases, that seems to make more sense to me. In your version > we'd have called enable_statement_timeout() twice consecutively (which > behaviourally is harmless). > > What do you think? I've not really tested this with the extended protocol, > so I'd appreciate if you could rerun your test from the older thread. The patch looks good and cleaner. It looks like the code works as expected. As before, I ran one INSERT statement with PgJDBC, with gdb's breakpoints set on enable_timeout() and disable_timeout(). I confirmed that enable_timeout() is called just once at Parse message, and disable_timeout() is called just once at Execute message. I'd like to wait for Tatsuo-san's thorough testing with pgproto. Regards Takayuki Tsunakawa
Commits
-
Rearm statement_timeout after each executed query.
- f8e5f156b30e 11.0 landed