RE: Timeout parameters
| От | MikalaiKeida@ibagroup.eu |
|---|---|
| Тема | RE: Timeout parameters |
| Дата | |
| Msg-id | OFBFC3FA80.8323A78D-ON432583BE.00319AF7-432583BE.003283B8@iba.by обсуждение исходный текст |
| Ответ на | RE: Timeout parameters ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
| Ответы |
RE: Timeout parameters
|
| Список | pgsql-hackers |
> Oops, unfortunately, PQcancel() does not follow any timeout parameters... It uses a blocking socket.
> Also, I still don't think it's a good idea to request cancellation. socket_timeout should be sufficiently longer than the usually expected query execution duration. And long-running queries should be handled bystatement_timeout which indicates the maximum tolerable query execution duration.
> For example, if the usually expected query execution time is 100 ms, statement_timeout can be set to 3 seconds and socket_timeout to 5 seconds.
Based on your comment it seems to me that 'socket_timeout' should be connected with statement_timeout. I mean that end-user should wait statement_timeout + 'socket_timeout' for returning control. It looks much more safer for me.
Best regards,
Mikalai Keida
> Also, I still don't think it's a good idea to request cancellation. socket_timeout should be sufficiently longer than the usually expected query execution duration. And long-running queries should be handled bystatement_timeout which indicates the maximum tolerable query execution duration.
> For example, if the usually expected query execution time is 100 ms, statement_timeout can be set to 3 seconds and socket_timeout to 5 seconds.
Based on your comment it seems to me that 'socket_timeout' should be connected with statement_timeout. I mean that end-user should wait statement_timeout + 'socket_timeout' for returning control. It looks much more safer for me.
Best regards,
Mikalai Keida
В списке pgsql-hackers по дате отправления: