Comment 6 for bug 865859

I kept working on this, and it went away permanently when I added SELECT SQL_NO_CACHE ... to my query. This means that its not this application, but some bug in MySQL that is causing it. Maybe this wrapper should detect such locks in some way and give an error return.

My application looped, scanning for changes in large blobs, read them in, then write them out to another connection (changes detected using hashes). I found that everything would work until I killed the application in the middle of a query. It seems that if you run a query that will return a bunch of blobs, then kill it after it executed and before it has finished returning results, running that EXACT SAME QUERY again will produce the above behavior. MySQL's result set caching is based on the exact query text, so my guess is that, if a blob-returning query gets killed, the cached data becomes 'bad' in some way.

The really baffling thing is that, in that case, the MySQL processlist shows the query come in, get handled, then the server thinks the operation is complete (but the client is still waiting for data). I'm guessing there is a very rare case here, in which the server returns a non-traditional result (maybe not the normal error return we expect), and the wrapper is interpreting it as a normal "Ok, query was run, I'll send you the data now". If the sockets had timeout values, this might allow a workaround.