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.
