Re: Timeout parameters

Hello.

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