Reporting queries often have different requirements than operational queries.

Operational queries may have a business requirement for sub-second responsiveness. Allowing a time-out of, say, 2 minutes allows genuine long-running queries to run, but will guarantee that a bad query will eventually stop using resources.

Reporting queries, on the other hand, may genuinely require several hours to run, as accounting requirements are often orthogonal to operational requirements.

For large scale systems, the suggestion of having an optional time-out that is configured by connection sounds sensible. There are security model implications of this option - who is allowed to connect with no time-out?

I concur with the suggestion that only "in-loop" time be counted towards the time-out. Once again, reporting applications may issue a query that runs quickly, but take several hours to process the data. A prime real-life example is an itemized invoice for $20 million for a gas plant (1,500 pages printed).

I also agree that the need for DBA and user "kill query" options.

For a user kill query, how complex would it be to refactor the protocol so that it is non-blocking? If the socket was not blocked, then your "kill" could be sent through the same socket as the initial query was. Another use for a non-blocked socket would be query status inquiries. I am sure that there are more uses

A DBA kill would require a mechanism for identifying which query to kill, when a few hundred people might be executing the same query.