Hi sergey :) well 10.1 with kill and subquery :) nice feature :) maybe too much, but very nice 

Em 14/09/2013 13:58, "Sergei Golubchik" <serg@mariadb.org> escreveu:

Hi, Roberto!

On Sep 13, Roberto Spadim wrote:
>
> > My preference is to kill connection by thread_id and query by
> > query_id, because I normally either want to stop a particular query,
> > or stop all activity in particular connection. But it is
> > incompatible change.
> >
> there's mysql work with this kind of syntax?  i didn't found it at bug.mysql
> at mail list, Justin at Percona, talked about patchs in others forks maybe
> a single unique syntax is better than maridb only syntax, check message
> from MDEV description (copied from mail list):
>
> Justin Swanhartgreenlion@gmail.com Percona, Inc
>
> KILL THREAD THREAD_ID WITH QUERY_ID QUERY_ID
> and
> KILL QUERY THREAD_ID WITH QUERY_ID QUERY_ID
> and possibly
> KILL QUERY WITH QUERY_ID
>
> should be supported.  This is a very important and missing feature
> which is included in other forks.

It's not in MySQL 5.6 and not in Percona Server 5.5 or 5.6.
I did not check Google patches, Facebook patches and other sets of MySQL
patches, though.

i didn`t found too :/ 

> my problem isn't the program allowing a kill command since it can restart
> the work or stop, it's not a problem
> the "problem" is the boring time lost at a wrong kill command, since i use
> persistent connections at php, and a thread running a script can be used in
> another script without changing it thread_id (can be confirmed at show
> processlist)
> my problem is sending a kill command to the wrong thread since i'm using
> the thread_id to kill the connection and not the query_id, check i use
> "kill connection xxx" not "kill query xxx"

Okay... This makes sense. If you use a connection pool that, indeed,
connection id does not correspond to a logical connection.

Still, while KILL CONNECTION QUERY_ID is kind of ok, KILL QUERY QUERY_ID
is very silly. I'd rather allow subqueries in KILL, to support

kill query query_id is very ugly hehehe, kill query id is ok, and kill connection query_id or query id with space is ok too 

 

  KILL CONNECTION (select thread_id from information_schema.processlist
                   where ...)

then you won't need to kill by query id or state or if_idle - you can
have everything in the where clause.

but this is a larger change that we cannot do 10.0, we simply don't have
time for it. We could try to do it in 10.1 though, properly and
generally, so that you can kill using as complex conditions as you like.
Instead of creating many limited shortcut syntax variants for special
cases.

yeah =) in future we can go back and do some job here

 

> i'm not using the threadpool yet and i don't know how processlist is
> reported with thread pool, is the id isn't unique in this case (using
> threadpool)?

Unique. Every connection has its own connection id, with or without
thread pool. Internal scheduling implementation doesn't affect
user-visible connection ids.

nice i will test thread pool and check how it works

 

> i don't know if it's what mariadb/mysql should do inside code when using
> threadpool, i'm using only one process per connection, and don't have this
> kind of problem

threadpool doesn't have this problem either.

> other doubt now... when we have a daemon process (plugin) there's a
> query id for it?

No.

> query_id=0? in this case we only have an "unique query id" with
> thread_id+query_id? maybe we should avoid the KILL QUERY_ID = 0

Right, thanks.

> again about sintax... maybe a WHERE could be added to KILL instead of a
> DELETE FROM INFORMATION_SCHEMA...
>
> KILL [CONNECTION | QUERY] [WHERE some_fields some_operators some_values
> and_no_subquery | <thread_id> | QUERY_ID <query_id>]
>
> about WHERE, we could use the same fields of show processlist:
>
> ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO, TIME_MS, STAGE,
> MAX_STAGE, PROGRESS, MEMORY_USED, EXAMINED_ROWS, QUERY_ID

I'd rather allow subqueries there, it'll be much more natural.

yes maybe information schema engine, or kill subquery?

 

Regards,
Sergei

bye :)