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

From Tatsuo Ishii
Subject Re: Statement timeout behavior in extended queries
Date
Msg-id 20170404.161032.1738592824395731468.t-ishii@sraoss.co.jp
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  (Tatsuo Ishii <ishii@sraoss.co.jp>)
Re: Statement timeout behavior in extended queries  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
>> 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.

Yes, Tsunakawa-san is correct. Sorry for confusion.

> 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.

Andres,

If you don't mind, could you please fix the comments and push it.

> 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.

That will be great.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: Parallel Append implementation
Next
From: Pavel Stehule
Date:
Subject: proposal: Introduction a commontype as new polymorphic type