Re: Timeout parameters - Mailing list pgsql-hackers

Hello.

At Thu, 14 Mar 2019 12:33:38 +0300, MikalaiKeida@ibagroup.eu wrote in
<OF3AC3E296.5DE954A0-ON432583BD.002E7144-432583BD.00348536@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