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.
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 |