maria-developers team mailing list archive
Mailing list archive
Re: [Commits] Rev 3192: Added new options to KILL. New syntax is KILL [HARD|SOFT] [CONNECTION|QUERY] [ID | USER user_name] in lp:maria/5.3
On Sep 26, Michael Widenius wrote:
> Sergei> A question.
> Sergei> Should "KILL USER my_name" also kill the current connection, or it
> Sergei> should only kill all other connections?
> If you do 'kill QUERY USER ...' then there should not be any issue.
> If you do 'kill connection USER CURRENT_USER()' then also your current
> connection will be killed so one better have reconnect working on the
> As one can kill ones own connection with 'kill thread_id' I didn't
> think much about if this is a problem or not.
I didn't say it's a problem. And of course, one can kill his own
connection. I asked a question about what could be a more useful
behavior for "KILL USER myself" - to kill the originating connection or
But I'm personally fine with either outcome.
> >> === modified file 'storage/archive/ha_archive.cc'
> >> --- a/storage/archive/ha_archive.cc 2011-07-05 19:46:53 +0000
> >> +++ b/storage/archive/ha_archive.cc 2011-09-22 22:13:38 +0000
> >> @@ -17,6 +17,7 @@
> >> #pragma implementation // gcc: Class implementation
> >> #endif
> >> +#define MYSQL_SERVER 1
> Sergei> why?
> Because the storage engine needs to get access to all the MYSQL_SERVER
> flags and not only the client flags. The other engine we have also
> defines this flag (at least ha_myisam.cc, ha_maria.cc which I looked
No, this is very wrong. Storage engines should not define MYSQL_SERVER -
they generally should only access only data and definitions that are
visible without MYSQL_SERVER. Definitions protected by MYSQL_SERVER are
internal server stuff, not designed for storage engine consumption.
There are certain engines that do access internal server stuff anyway -
MyISAM and Aria being two of those (and XtraDB, for example). But a
"proper" engine should not do that, and many engines do not. For
example, InnoDB developers worked hard to remove all dependencies on
MySQL internals from their engine, and now InnoDB does not need
MYSQL_SERVER (although, it might change again in the future :).
But anyway, if an engine does not need MYSQL_SERVER - it should not
define it. If an engine really needs it - it should be changed not to.