At 03:27 AM 3/02/2004 +0100, you wrote:

>I rather figured that if the server were to be smart enough to cancel a
>query because nobody's listening, it would also cancel the send-buffer for
>that connection.

It's not listening for clients that are connected but doing nothing. It
listening for connections that don't respond for a certain period (120
seconds, I think, on Windows). So it will clean up after a client crashes
but there's no way to speed up the disconnection if the client requests
disconnection while still fetching. The client can *think* it's
disconnected because it requested to disconnect. The server has to wrap up
the transaction first. It can't do that until its finished delivering what
the transaction requested. It's very democratic. :-)

The client has no way to say "I asked for 10,000,000 rows but I don't want
the other 9,999,999". It has to ask for what it wants and be prepared to
live with what it gets. So it's just going to keep outputting the rows
and, when it's done, it will proceed through the rest of the steps to
complete the disconnect.

It's not nice to crash out of the connection, either, in the hope that it
will be faster than letting nature take its course. If the server happens
to be doing a sweep out of that connection, you'll corrupt data.

/hb