Re: [Maria-developers] More Secure Kill Command
Hi, Roberto! On Aug 17, Roberto Spadim wrote:
Hi sergei, What about give two informations, thread id and query id If thread id and query id is equal, kill it
There's no need to. Query id identifies the query and the connection unambiguously. Specifying also a thread id is redundant. Regards, Sergei
nice, but... i was locking the mysql protocol... http://dev.mysql.com/doc/internals/en/com-process-kill.html#packet-COM_PROCE... it say that we kill a process (ok it's not a SQL command (COM_QUERY)) in few less words... we could add a SQL command to KILL ID <query id> (nice! we don't need thread id + query id, i like some redundant information to make my self more secure :P, but since query id can be a 64bits value i think i will not have time to overflow the query id and get the same query id in less than 1 second) and we could add a new protocol command (i don't know if it's nice... because add this is incompatible with mysql protocol, and probably will only work with mariadb client library...), but, if we want to add it, could be nice add a new parameter (optional) about the query id, instead of only KILL and thread_id, add a KILL null (or 0 if thread id can't be 0), and a query id, to KILL protocol
Hi, Roberto! On Aug 17, Roberto Spadim wrote:
nice, but... i was locking the mysql protocol... http://dev.mysql.com/doc/internals/en/com-process-kill.html#packet-COM_PROCE... it say that we kill a process (ok it's not a SQL command (COM_QUERY)) in few less words...
I don't see any reason why I should care about kill with the query id using the protocol command COM_PROCESS_KILL. SQL statement KILL QUERY ID is enough for most practical purposes. Regards, Sergei
hi sergei =D nice! i don't see reasons too :D just to don't forget about it, and don't add more work :) could / should we create a MDEV for it?
i write one MDEV (hehe sorry don't wait you reply), check if it's nice, if not just close it, or change description =] https://mariadb.atlassian.net/browse/MDEV-4911
sergei... one more point... i was looking the mk-kill http://linux.die.net/man/1/mk-kill there's some cases where we want to kill a thread that's no running any query and we need to kill it only when it is not running any query, in other words i can't use kill thread id, i must use kill query id.... the point here is "how query id is increased?" for example.. (query id = 0 thread id = 10) <- kill query id =0 [query received] query id ++ (query id = 1 thread id = 10) SELECT * FROM TABLE <- kill query id =1 [query done] (query id = 1 thread id = 10) <- kill query id =1 [query received] query id ++ (query id = 2 thread id = 10) SELECT * FROM TABLE <- kill query id =2 [query done] (query id = 2 thread id = 10) <- kill query id =2 (query id = 2 thread id = 10) <- kill query id =2 if i send a KILL QUERY ID = 2, i will only kill the last SELECT, or if the select is done, i will kill the thread with the last executed query id = 2 see the problem? the query id can't be reseted, and it MUST be increased only when we START a new query, not at the end of query, example: (query id = 0 thread id = 10) <- kill query id =0 [query received] (query id = 0 thread id = 10) *SELECT * FROM TABLE <- kill query id =0* query id ++ (query id = 1 thread id = 10) [query done] *(query id = 1 thread id = 10) <- **kill query id =1 !!!!* [query received] (query id = 1 thread id = 10) *SELECT * FROM TABLE <- kill query id =1 !!!!* query id ++ (query id = 2 thread id = 10) [query done] (query id = 2 thread id = 10) <- kill query id =2 --- Is the QUERY ID increased ONLY WHEN A QUERY START, AND the QUERY ID isn't reseted AFTER query execution? If yes, this is ok, we can kill a thread that is not running a query without problems using query id in this case no problems... bye
humm... i will think more about this... maybe i'm too crazy (and unlucky)
to understand that the order isn't important...
i will check again what i write in last email...
please check too and tell me if the order of increase isn't a problem
2013/8/17 Roberto Spadim
sergei... one more point... i was looking the mk-kill http://linux.die.net/man/1/mk-kill
there's some cases where we want to kill a thread that's no running any query and we need to kill it only when it is not running any query, in other words i can't use kill thread id, i must use kill query id.... the point here is "how query id is increased?" for example..
(query id = 0 thread id = 10) <- kill query id =0
[query received] query id ++ (query id = 1 thread id = 10) SELECT * FROM TABLE <- kill query id =1 [query done] (query id = 1 thread id = 10) <- kill query id =1
[query received] query id ++ (query id = 2 thread id = 10) SELECT * FROM TABLE <- kill query id =2 [query done] (query id = 2 thread id = 10) <- kill query id =2
(query id = 2 thread id = 10) <- kill query id =2
if i send a KILL QUERY ID = 2, i will only kill the last SELECT, or if the select is done, i will kill the thread with the last executed query id = 2
see the problem? the query id can't be reseted, and it MUST be increased only when we START a new query, not at the end of query, example:
(query id = 0 thread id = 10) <- kill query id =0
[query received] (query id = 0 thread id = 10) *SELECT * FROM TABLE <- kill query id =0* query id ++ (query id = 1 thread id = 10) [query done] *(query id = 1 thread id = 10) <- **kill query id =1 !!!!*
[query received] (query id = 1 thread id = 10) *SELECT * FROM TABLE <- kill query id =1 !!!!* query id ++ (query id = 2 thread id = 10) [query done] (query id = 2 thread id = 10) <- kill query id =2
--- Is the QUERY ID increased ONLY WHEN A QUERY START, AND the QUERY ID isn't reseted AFTER query execution?
If yes, this is ok, we can kill a thread that is not running a query without problems using query id in this case no problems...
bye
-- Roberto Spadim SPAEmpresarial
I end my "mind work" :P YES we need that query id increment ONLY at START of query... We CAN'T kill a FUTURE query, we MUST kill the CURRENT QUERY running, or the CURRENT THREAD Increment at query end will kill future queries, check : 1) id=0 2) select.... (id=0) 3) (id=1) 4) select ... (id=1) if i send kill query id =1, at third line, i will kill the thread, if i wait more time i will kill the query running (NOOOO I CAN'T DO THIS), but in this order: 1) id=0 2) select.... (id=1) 3) (id=1) 4) select ... (id=2) if i send kill query id=1, at third line, i will kill the thread, if i wait more time i WILL NOT kill query and WILL NOT KILL the thread, NICE! THAT'S THE IDEA!
patch sent :D please check it at MDEV-4916
2013/8/17 Roberto Spadim
I end my "mind work" :P
YES we need that query id increment ONLY at START of query...
We CAN'T kill a FUTURE query, we MUST kill the CURRENT QUERY running, or the CURRENT THREAD Increment at query end will kill future queries, check :
1) id=0 2) select.... (id=0) 3) (id=1) 4) select ... (id=1)
if i send kill query id =1, at third line, i will kill the thread, if i wait more time i will kill the query running (NOOOO I CAN'T DO THIS), but in this order:
1) id=0 2) select.... (id=1) 3) (id=1) 4) select ... (id=2)
if i send kill query id=1, at third line, i will kill the thread, if i wait more time i WILL NOT kill query and WILL NOT KILL the thread, NICE! THAT'S THE IDEA!
-- Roberto Spadim SPAEmpresarial
some things that must be done: 1) the KILL QUERY_ID 1,2,3,4,5 don't work, that's my first patch with sql_yacc.yy maybe i done something wrong since %expect changed +8 numbers 2) the QUERY_ID isn't what i want but well worked hehehehe, maybe change the syntax and make it more beautiful 3) there's some warnings in gcc that must be checked (signed compare with unsigned), and others case) that don't use the right flag (i add a bit = 16 for KILL_QUERY command) 4) the KILL QUERY_ID <non exists query id>, return a error something like "thread id not found", must be "query id not found" 5) i don't remember if have other problem...
participants (2)
-
Roberto Spadim -
Sergei Golubchik