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

From 'Andres Freund'
Subject Re: Statement timeout behavior in extended queries
Date
Msg-id 20170405014540.n6rx7tkz3jzcets4@alap3.anarazel.de
Whole thread Raw
In response to Re: Statement timeout behavior in extended queries  ('Andres Freund' <andres@anarazel.de>)
Responses Re: Statement timeout behavior in extended queries  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On 2017-04-04 16:56:26 -0700, 'Andres Freund' wrote:
> On 2017-04-04 23:52:28 +0000, Tsunakawa, Takayuki wrote:
> > From: Andres Freund [mailto:andres@anarazel.de]
> > > Looks to me like npgsql doesn't do that either.  None of libpq, pgjdbs and
> > > npgsql doing it seems like some evidence that it's ok.
> > 
> > And psqlODBC now uses always libpq.
> > 
> > Now time for final decision?
> 
> I'll send an updated patch in a bit, and then will wait till tomorrow to
> push. Giving others a chance to chime in seems fair.

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.

- Andres

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: partitioned tables and contrib/sepgsql
Next
From: Tatsuo Ishii
Date:
Subject: Re: Statement timeout behavior in extended queries