RE: Timeout parameters
От | Tsunakawa, Takayuki |
---|---|
Тема | RE: Timeout parameters |
Дата | |
Msg-id | 0A3221C70F24FB45833433255569204D1FB5E336@G01JPEXMBYT05 обсуждение исходный текст |
Ответ на | RE: Timeout parameters (Fabien COELHO <coelho@cri.ensmp.fr>) |
Ответы |
RE: Timeout parameters
|
Список | 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_TIMEOUThere: 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 ofusing 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
В списке pgsql-hackers по дате отправления: