Obviously I'm wrong, but I would expect that if the server can respond via another
connection then it should be able to kill the unresponsive one? It should
have control over it's own threads.
When the rogue query is running the server is still very responsinve to other
queries, now connections and administrative requiests (ie, SHOW PROCESSLIST)...
At this time the server itself is not totaly unresponsive (except on a single
processor win32 machine, when a bad query runs, you might as well step
away from the computer and go get a cup of coffee).. On unix or multi-proc win32
the server is still happy to perform new requests..
Quentin Bennett wrote:
>
> Hi
>
> I think that kill will only take effect when the server pays attention - if
> it is busy (calculating statistics), then it may not respond immediately.
>
> Regards
>
> Quentin
>
> -----Original Message-----
> From: Steve Ruby [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, 8 March 2001 5:19 a.m.
> To: [EMAIL PROTECTED]
> Subject: Re: kill bad query
>
> Steve Ruby wrote:
> >
> > If I have a connection that executes a bad query shouldn't I
> > ALWAYS be able to kill it with "kill <connect num>"?
> >
> > I have a query that keeps getting stuck, (who knows what
> > it is doing) but that State is "statistics"
> >
> > I can't ever kill it without taking down the server..
> >
>
> PS.. this is using 3.23.33 on Linux.. I find that the query is very
> slow but will eventually complete, still, can I not kill a query
> that will lock
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
