I understand the main aim of your suggestion that a client application has to do a lot of work except making quires to the database. I agree with you that "client-side timeout" has to be integrated into the PostgreSQL server and libpq. I'm with Fabien that "client-side timeout" seems unsafe. Also I agree with Fabien that quire can take much time to be processed by the PosgtreSQL server and it is a normal behavior. There is possible that performance of the PostgreSQL server machine can be low temporary or continuously, especially during upgrading procedure. I think it is important to add some more information into the description of this parameter which informs end-users that this parameter has to be used very carefully because it can impact as on the client application as on the server.
> You mentioned about when a SQL query is heavy, but I want to talk about when OS hang. > If OS hang occurs, the cost of cancel request processing is so high.
Such a situation looks to be covered by TCP_USER_TIMEOUT and keep_alive mechanisms. May be it is better to warn in documentation or prohibit in the source code to set "client-side timeout" less than TCP_USER_TIMEOUT to avoid handling "possible" logical problems ahead to the network problems. Keep in mind that "client-side timeout" can abort a connection which uses UNIX-domain sockets too.