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 0A3221C70F24FB45833433255569204D1F6C0A6B@G01JPEXMBYT05
Whole thread Raw
In response to Re: Statement timeout behavior in extended queries  ('Andres Freund' <andres@anarazel.de>)
List 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
withPgJDBC, with gdb's breakpoints set on enable_timeout() and disable_timeout().  I confirmed that enable_timeout() is
calledjust 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





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: partitioned tables and contrib/sepgsql
Next
From: Peter Eisentraut
Date:
Subject: Re: partitioned tables and contrib/sepgsql