maria-developers team mailing list archive

[Eric Bergen <eric.bergen@xxxxxxxxx>]

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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~maria-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Eric Bergen
eric.bergen@xxxxxxxxx
http://www.ebergen.net