RE: Timeout parameters

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

Why?

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 
connection?

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

-- 
Fabien.