maria-developers team mailing list archive

[Roberto Spadim <roberto@xxxxxxxxxxxxx>]

Hi! MDEV Created

   1. MDEV-5018 <https://mariadb.atlassian.net/browse/MDEV-5018>



2013/9/14 Roberto Spadim <roberto@xxxxxxxxxxxxx>

> 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@xxxxxxxxxxx> 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@xxxxxxxxx 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 :)
>



-- 
Roberto Spadim
SPAEmpresarial