Hello, all. The main subject of discussion in this thread relates to the 'socket_timeout'. As I understand there is no any hesitation about applying TCP_USER_TIMEOUT into the PostgreSQL. We have been waiting for applying TCP_USER_TIMEOUT in PostgreSQL for about 6 moths. Fabien, I was wondering whether you can apply TCP_USER_TIMEOUT patch and continue discussion about 'socket_timeout'?
> I can't imagine that in the cases where other than applications > cannot be rebuild for some reasons. (E.g. the source code has > been lost or the source code no longer be built on modern > environment..) > If an application is designed to have such a requirement, mustn't > it have implemented that by itself by any means? For example, an > application on JDBC can be designed to kill a querying thread > that takes longer than threshold. Kyotaro-san, I am afraid you are mistaken in your statement about JDBC. JDBC is an another level of abstraction which provides only an universal Java interface to interact with different databases. There is the same ODBC driver which provides an universal C interface to interact with different databases. So, the 'socket_timeout' seems to be a part of functionality of ODBC driver. libpq provides two interfaces: pqWait() which waits for a socket state forever and psTimedWait() which waits for a socket state for an appropriate timeout. This functionality seems to be enough. I agree with Robert Haas that this parameter can make a mess in the head of PostgreSQL user because it is very difficult to understand the case when each timeout parameter, which is provided by PostgreSQL, works. > For example, OS issues such as abnormally (buggy) slow process scheduling or paging/swapping that prevent control from being passed to postgres. Or, abnormally long waits on lwlocks in postgres. statement_timeout doesn't take effect while waiting on a lwlock. I have experienced both. And, any other issues in the server that we haven't experienced and not predictable. For me all mentioned by Takayuki Tsunakawa problems looks like a lack of design of end-user application or configuration of DB server. It is not a problem of PostgreSQL. Best regards, Mikalai Keida
