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 20170404064820.jyj7s6b7bwbmfxpc@alap3.anarazel.de
Whole thread Raw
In response to Re: Statement timeout behavior in extended queries  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Responses Re: Statement timeout behavior in extended queries  (Tatsuo Ishii <ishii@sraoss.co.jp>)
List pgsql-hackers
On 2017-04-04 06:35:00 +0000, Tsunakawa, Takayuki wrote:
> From: Andres Freund [mailto:andres@anarazel.de]
> Given the concern raised in
> > http://archives.postgresql.org/message-id/12207.1491228316%40sss.pgh.p
> > a.us
> > I don't see this being ready for committer.
> 
> If what Tatsuo-san said to Tom is correct (i.e. each Parse/Bind/Execute starts and stops the timer), then it's a
concernand the patch should not be ready for committer.  However, the current patch is not like that -- it seems to do
whatothers in this thread are expecting.
 

Oh, interesting - I kind of took the author's statement as, uh,
authoritative ;).  A quick look over the patch confirms your
understanding.

I think the code needs a few clarifying comments around this, but
otherwise seems good.  Not restarting the timeout in those cases
obviously isn't entirely "perfect"/"correct", but a tradeoff - the
comments should note that.

Tatsuo-san, do you want to change those, and push?  I can otherwise.

Unfortunately I can't move the patch back to the current CF, but I guess
we can just mark it as committed in the next.

- Andres



pgsql-hackers by date:

Previous
From: Neha Khatri
Date:
Subject: Re: strange parallel query behavior after OOM crashes
Next
From: Amit Khandekar
Date:
Subject: Re: Parallel Append implementation