As part of adding per query table/index statistics I added a per thread query_id. This would serve your purpose too. You could do kill connection_id query_id and be guaranteed of killing the query you want on a specific connection. On Fri, Aug 16, 2013 at 2:31 PM, Roberto Spadim <roberto@spadim.com.br> wrote:
Hi guys i was mailing at maria-discuss, but i think it a new feature, and want some view point from developers... check this problem:
connection 1) big select... connection 2) show processlist connection 1) other query connection 2) kill connection 1 id (i take +- 1 second between show processlist and this command) connection 1) killed
the problem? the kill connection 1 (KILL thread_id) killed the wrong query could we implement something like:
KILL [CONNECTION | QUERY] thread_id [QUERY "some relative unique query id in this database"]
the relative unique query id, could be: substr(sha1 or md5 of (thread_id + query start time),0,6) (6 hex numbers is good?) it's like a git small hash commit id, maybe we could make it more unique... but since i will not use it very often, i think a less intensive work is nice here... a global query id could add more one lock for every query...
example: KILL 1 QUERY "abcdef"
the "abcdef" = substr(MD5( thread id + query start time ),0,6)
we could add client ip or others unique information about this query, but something that don't increase (ok just a little) the load of a show processlist / select * from information_schema
thanks
-- Roberto Spadim
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
-- Eric Bergen eric.bergen@gmail.com http://www.ebergen.net