Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Won't Fix
-
10.0.21, 10.0, 10.1
-
None
Description
SELECT * FROM mysql.spider_tables \G |
*************************** 1. row ***************************
|
db_name: x
|
table_name: s
|
link_id: 0
|
priority: 1000000
|
server: NULL |
scheme: NULL |
host: 127.0.0.1
|
port: NULL |
socket: NULL |
username: root
|
password: proot |
ssl_ca: NULL |
ssl_capath: NULL |
ssl_cert: NULL |
ssl_cipher: NULL |
ssl_key: NULL |
ssl_verify_server_cert: 0
|
default_file: NULL |
default_group: NULL |
tgt_db_name: NULL |
tgt_table_name: NULL |
link_status: 1
|
1 row in set (0.00 sec) |
SHOW PROCESSLIST;
|
+----+------+-------------------+------+---------+------+----------------------+-----------------------------------------+----------+ |
| Id | User | Host | db | Command | Time | State | Info | Progress | |
+----+------+-------------------+------+---------+------+----------------------+-----------------------------------------+----------+ |
| 32 | root | 172.17.42.1:35121 | test | Query | 3 | After opening tables | SELECT * FROM information_schema.TABLES | 0.000 | |
| 45 | root | 172.17.42.1:35145 | test | Query | 0 | init | SHOW PROCESSLIST | 0.000 |
|
| 47 | root | 127.0.0.1:43968 | x | Query | 3 | After opening tables | show table status from `x` like 's' | 0.000 | |
+----+------+-------------------+------+---------+------+----------------------+-----------------------------------------+----------+ |
Connection 32 will wait forever or for a long time (not sure). I can KILL connection 47, but connection 32 will say that MySQL server has gone away.
Connection 47 will also block:
- DROP TABLE x.s
- FLUSH TABLES
- maybe others...
The solution is not that hard (KILL 47; DROP TABLE x.s), but I think that SPIDER should detect the problem and return an error to the user. Or maybe SPIDER shouldn't open that connection at all.
If this is not a bug, please consider it as a feature request.