Horton

RE: Timeout parameters

Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>

View thread View on postgr.es
From: "Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>
To: 'Fabien COELHO' <coelho@cri.ensmp.fr>, "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>
Cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>, "AYahorau@ibagroup.eu" <AYahorau@ibagroup.eu>
Date: 2018-12-27T08:25:06Z
Lists: pgsql-hackers 
From: Fabien COELHO [mailto:coelho@cri.ensmp.fr]
> I still do not understand the use-case specifics: for me, aborting the
> connection, or a softer cancelling the statement, will result in the
> server stopping the statement, so the server does NOT "continue the job",
> so I still do not see how it really differs from the server-side
> statement_timeout setting.

How about when the server is so saturated that statement_timeout cannot work?  See SQLNET.SEND_TIMEOUT and SQLNET.RECV_TIMEOUT here:

https://docs.oracle.com/cd/E11882_01/network.112/e10835/sqlnet.htm#NETRF228

As these parameter names suggest, maybe we could use SEND_TIMEO and RECV_TIMEO socket options for setsockopt() instead of using pqWaitTimed().

To wrap up, the relevant parameters work like this:

* TCP keepalive and TCP user (retransmission) timeout: for network problems
* statement_timeout: for long-running queries
* socket_timeout (or send/recv_timeout): for saturated servers


FYI, PgJDBC has a parameter named socketTimeout:

https://jdbc.postgresql.org/documentation/head/connect.html#connection-parameters


Regards
Takayuki Tsunakawa

Commits

  1. Add support TCP user timeout in libpq and the backend server