|From:||'Andres Freund' <andres(at)anarazel(dot)de>|
|To:||"Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>|
|Cc:||'Tatsuo Ishii' <ishii(at)sraoss(dot)co(dot)jp>, "david(at)fetter(dot)org" <david(at)fetter(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: Statement timeout behavior in extended queries|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2017-04-04 06:35:00 +0000, Tsunakawa, Takayuki wrote:
> From: Andres Freund [mailto:andres(at)anarazel(dot)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 concern and the patch should not be ready for committer. However, the current patch is not like that -- it seems to do what others 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
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.
|Next Message||Amit Khandekar||2017-04-04 07:07:59||Re: Parallel Append implementation|
|Previous Message||Neha Khatri||2017-04-04 06:46:18||Re: strange parallel query behavior after OOM crashes|