RE: Timeout parameters

From: MikalaiKeida(at)ibagroup(dot)eu
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu>, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, "Jamison, Kirk" <k(dot)jamison(at)jp(dot)fujitsu(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: RE: Timeout parameters
Date: 2019-03-14 11:01:06
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hello, Takayuki.

> > > For example, OS issues such as abnormally (buggy) slow process
> > or paging/swapping that prevent control from being passed to postgres.
> > abnormally long waits on lwlocks in postgres. statement_timeout
> > take effect while waiting on a lwlock. I have experienced both. And,
> > other issues in the server that we haven't experienced and not
> >
> > For me all mentioned by Takayuki Tsunakawa problems looks like a lack
> > design of end-user application or configuration of DB server. It is
> > a problem of PostgreSQL.

> Certainly, my cases could be avoided by the OS and database
configuration. But we cannot say all such problems can be avoided by
configuration in advance. The point is to provide a method to get ready
for any situation.

Do you mind me asking you whether you have thought that solving your
problem can lead to the problem in the other user applications?
Let's imagine a possible problem:
1. end-user sets 'socket_timeout' only for current session
2. 'socket_timeout' is much shorter than 'keep_alive', 'tcp_user_timeout'
and 'statement_timeout'
3. end-user invokes a 'heavy' query which is not be possible to process by
PostgreSQL server within 'socket_timeout'
4. if the query fails due to timeout, terminate the session and repeat it

As the query is not cancelled, PostgreSQL server will process it till
completion or 'statement_timeout' expiration. In such a case PostgreSQL
server can be overloaded by an 'unreliable' user/users and other end-users
will not be able to work with PostgreSQL server as they expected.

There are a number of timeout parameters which can lead to the terminating
a query:
1. keep_alive and tcp_user_timeout terminate a query because of network
2. statement_timeout terminates a query because the time for processing
this query by PostgreSQL server expired.

These timeouts are absolutely different and do not interact with each
other. Suggested 'socket_timeout' can replace all mentioned by me timeout
parameters because of willing of 'selfish' end-user.

'SocketTimeout' in JDBC was added to cope with network problems when
keep_alive and tcp_user_timeout were not implemented. Implementation of
the 'socket_timeout' looks like adding a bug into the libpq. I think that
the problems you faced, relate to the other issues in PostgreSQL.

Best regards,
Mikalai Keida

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-03-14 11:06:45 Re: libpq environment variables in the server
Previous Message Heikki Linnakangas 2019-03-14 11:00:25 Re: Making all nbtree entries unique by having heap TIDs participate in comparisons