Hello. At Thu, 14 Mar 2019 12:33:38 +0300, mikalaike...@ibagroup.eu wrote in <of3ac3e296.5de954a0-on432583bd.002e7144-432583bd.00348...@iba.by> > 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.
I think I'm not mistaking that. Java is just an example. What I said is such kind of timeout can be implemented everwhere. If the lower layer has the feature, the upper-layer is implmeneted more easily, but in contrast the the feature gets generic and could be obscure for upper-layers. The socket_timeout seems that kind of feature. (Yes, implementing such timeouts in C is harder than in Java.) So the socket_timeout seems to me as if it is provided as a plaster to mend a badly-designed systems. Maybe as mentioned below. > 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. It's my concern. regards. -- Kyotaro Horiguchi NTT Open Source Software Center
