Hello Takayuki-san, > Yes, so I think it would be necessary to describe how to set socket_timeout with relation to other timeout parameters -- socket_timeout > statement_timeout, emphasizing that socket_timeout is not for canceling long-running queries but for returning control to the client.
For me it does not look enough. If you would like to implement the 'socket_timeout' parameter, could you pay attention on the Fabien Coelho comment? > The fact that no answer data is received may mean that it takes time to > compute the result, so cancelling seems appropriate to me, rather than > severing the connection and starting a new one immediately, leaving the > server loaded with its query. This comment is very important to pay attention on. Let's imagine once more: 1. end-user makes a query 2. the query has not completed within this timeout due to any reason: the query is too 'heavy', some problem with OS happened, PostgreSQL server terminated 3. if we simple close connection, the first case is negative by mistake. To avoid such a situation I think it would be better to call a PQcancel(). In case of failure PQcancel() terminates in 'socket_timeout'. So, control to the end-user in such a failure situation will be returned in 2 * 'socket_timeout' interval. It is much better than hanging forever in some specific cases. Moreover, such solution will not lead to the overloading of PostgreSQL server by abnormally ignored 'heavy' queries results by end-users. What do you think about it? Best regards, Mikalai Keida
