From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | andres(at)anarazel(dot)de |
Cc: | ishii(at)sraoss(dot)co(dot)jp, tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, david(at)fetter(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Statement timeout behavior in extended queries |
Date: | 2017-04-05 01:05:19 |
Message-ID: | 20170405.100519.31796070195459088.t-ishii@sraoss.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-04-05 01:05:25 | Outdated comments around HandleFunctionRequest |
Previous Message | Tatsuo Ishii | 2017-04-05 00:45:48 | Re: pgbench - allow to store select results into variables |