maria-developers team mailing list archive

[Eric Bergen <eric.bergen@xxxxxxxxx>]

If you're going to add support for killing queries in a specific state
then why not just add the ability to pass in a state? I can see some
use cases for killing queries in a specific state that are more useful
than sleep.

Off the top of my head:
Killing a query while it is waiting for table lock. This would be
especially handy for things like alter table or a big update where you
want to kill it only if it is waiting on a lock but before it has done
any modifications. This may be because it is holding the write lock
and causing other queries to pileup and you know the rollback will be
fast.

It may also be useful to be able to kill queries in opening tables
state in a load shedder to try to quiet down table cache trashing. Or
maybe killing queries in unauthenticated state that are holding up the
accept thread waiting on a bad dns request.

I'm sure there are more state specific kill commands that would come in handy.


On Sun, Aug 18, 2013 at 3:49 AM, Roberto Spadim <roberto@xxxxxxxxxxxxx> wrote:
> Hi guys, i sent some patchs, could anyone check it?
> it have some things to do:
>
> query syntax isn't in the MDEV-4911, i did a QUERY_ID instead of a more
> comlpex syntax (since i never used bison before :P )
>
> the query_id works, but i need a new error message ( "Unknown query id: %")
>
> well i didn't make the gcc happy, there's some warnings, and i don't know if
> it's all right
>
> i send this patch after MDEV-4916 patch, in other words the %expect value of
> sql_yacc.yy is wrong if you don't apply the MDEV-4916 patch
>
> the 4916 is a IF_IDLE keyword to KILL command too
> it only kill if there's no query running
>
> well :) thanks guys!
>
> --
> 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