RE: Timeout parameters

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: "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-25 14:58:41
Message-ID: alpine.DEB.2.21.1812251546500.32444@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

>>> I'm not sure I understand the use case you have that needs these new
>>> extensions.

>> If you face the following situation, this parameter will be needed.
>> 1. The connection between the server and the client has been established
>> normally.
>> 2. A server process has been received SQL statement.
>> 3. The server OS can return an ack packet, but it takes time to execute
>> the SQL statement
>> Or return the result because the server process is very busy.
>> 4. The client wants to close the connection while leaving the job to the
>> server.
>> In this case, "statement_timeout" can't satisfy at line 4.


ISTM that "leaving the job" to the server with a client-side connection
closed is basically an abort, no different from what server-side
"statement_timeout" already provides?

Also, from a client perspective, if you use statement_timeout, it
would timeout, then the client would process the error and the connection
would be ready for the next query without needing to be re-created, which
is quite costly anyway? Also, if the server is busy, recreating an
connection is expensive so it won't help much, really?

So from your explanation above I must admit that I do not clearly
understand the use case for a client-side libpq-level SQL statement
timeout. I still need some convincing.

About the implementation, I'm wondering whether something simpler could be
done. Check how psql implements "ctrl-c" to abort a running query: it
seems that it sends a cancel message, no need to actually abort the

>>> I think that there is some kind of a misnomer: this is not a
>>> socket-level timeout, but a client-side query timeout, so it should be
>> named differently?
>> Yes, I think so.

Hmmm.... "client_statement_timeout" maybe?


In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-12-25 15:01:49 RE: Timeout parameters
Previous Message Fabien COELHO 2018-12-25 11:47:07 Re: pg_dump multi VALUES INSERT