From: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
---|---|
To: | 'Fabien COELHO' <coelho(at)cri(dot)ensmp(dot)fr>, "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>, "AYahorau(at)ibagroup(dot)eu" <AYahorau(at)ibagroup(dot)eu> |
Subject: | RE: Timeout parameters |
Date: | 2018-12-27 08:25:06 |
Message-ID: | 0A3221C70F24FB45833433255569204D1FB5E336@G01JPEXMBYT05 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
From: Fabien COELHO [mailto:coelho(at)cri(dot)ensmp(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2018-12-27 08:29:24 | Re: Speeding up creating UPDATE/DELETE generic plan for partitioned table into a lot |
Previous Message | Evgeniy Efimkin | 2018-12-27 07:54:54 | Re: [WIP] CREATE SUBSCRIPTION with FOR TABLES clause (table filter) |