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