Re: Statement timeout behavior in extended queries
От | Tatsuo Ishii |
---|---|
Тема | Re: Statement timeout behavior in extended queries |
Дата | |
Msg-id | 20170405.100519.31796070195459088.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Re: Statement timeout behavior in extended queries ('Andres Freund' <andres@anarazel.de>) |
Ответы |
Re: Statement timeout behavior in extended queries
|
Список | 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 по дате отправления: