Re: Timeout parameters

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Nagaura, Ryohei" <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com>, "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-13 06:05:05
Message-ID: alpine.DEB.2.21.1903130657490.4059@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hello Robert,

> <nagaura(dot)ryohei(at)jp(dot)fujitsu(dot)com> wrote:
>> 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.
>
> +1. If the server fails to detect that the client has gone away,
> that's the server's problem. The client is entirely entitled to be
> selfish if it so wishes.

With the current libpq implementation the server does not see that the
client has gone away on a trivial "pg_sleep", where the load is definitely
not an issue, so the server problem seems to be there already.

Also, I do not see the downside of sending a cancel query before severing
the connection. If it is not processed, too bad, but if it is then it is
for the better.

ISTM that the client can be selfish but nice about its timeout.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2019-03-13 06:17:47 Re: BUG #15668: Server crash in transformPartitionRangeBounds
Previous Message Masahiko Sawada 2019-03-13 06:03:46 Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits