Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.6, 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5(EOL)
-
None
Description
How to reproduce
1. Create a simple Spider table with one or more remotes, and insert a big load of records (in my case, 10,000,000 records).
2. On a shell session A, connect to Spider with a CLI client, fetch the whole table with "SELECT * FROM <table_name>", so it can take quite a while for remotes to finish.
3. Open another shell session B and connect to one of the remotes with a CLI client, then run "SHOW PROCESSLIST" and it should be seen the query is executing on the remote.
4. On shell session A, hit CTRL-C to kill the query on Spider, and should be able to see
^CCtrl-C -- query killed. Continuing normally.
|
^CCtrl-C -- query killed. Continuing normally.
|
ERROR 2013 (HY000): Lost connection to MySQL server during query
|
4. Switch to shell session B, run "SHOW PROCESSLIST" again, and it should be seen the query is still running.
5. Switch to shell session A again, start a new connection to Spider (since the last one was killed), run "SHOW PROCESSLIST", and the query on Spider is also still running (with a "killed" status).
What's the problem
There are two problems on this matter:
1. Spider does not check thd->killed frequently enough to be aware of the query status.
2. When/if Spider realizes the query is killed, it does not make effort to kill the propagated queries on remotes.