RE: Timeout parameters

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

Hi, Fabien-san.

> From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
> As I understand the "client-side timeout" use-case, as distinct from
> network-issues-related timeouts proposed in the other patches, the point is more
> or less to deal with an overloaded server.
The main purpose of this parameter is to avoid client's waiting for DB server infinitely, not reducing the server's burden.
This results in not waiting end-user, which is most important.
As Tsunakawa-san presented, there are similar parameters in JDBC and Oracle, so I think that this idea is valid.

> The timeout is raised because getting the result takes time, which may be simply
> because the query really takes time, and it does not imply that the server would
> not be able to process a cancel request.
You mentioned about when a SQL query is heavy, but I want to talk about when OS hang.
If OS hang occurs, the cost of cancel request processing is so high.
This is the reason why the implementation is just only disconnection without canceling.

Best regards,
---------------------
Ryohei Nagaura

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2019-03-11 02:27:08 Re: [HACKERS] WAL logging problem in 9.4.3?
Previous Message Haribabu Kommi 2019-03-11 02:17:37 Re: Pluggable Storage - Andres's take