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 20170405.100519.31796070195459088.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  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
> Hm. I started to edit it, but I'm halfway coming back to my previous
> view that this isn't necessarily ready.
> 
> If a client were to to prepare a large number of prepared statements
> (i.e. a lot of parse messages), this'll only start the timeout once, at
> the first statement sent.  It's not an issue for libpq which sends a
> sync message after each PQprepare, nor does it look to be an issue for
> pgjdbc based on a quick look.
> 
> Does anybody think there might be a driver out there that sends a bunch
> of 'parse' messages, without syncs?

What's your point of the question? What kind of problem do you expect
if the timeout starts only once at the first parse meesage out of
bunch of parse messages?

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: Tatsuo Ishii
Date:
Subject: Re: pgbench - allow to store select results intovariables
Next
From: Andres Freund
Date:
Subject: Outdated comments around HandleFunctionRequest