Re: Statement timeout behavior in extended queries

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

In response to

Responses

Browse pgsql-hackers by date

  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