- developers - lists.mariadb.org

[Maria-developers] MDEV-7628 Row-based replication of old DECIMAL to new DECIMAL
by Alexander Barkov 25 Feb '15

25 Feb '15

Hi Sergei, Kristian, all, Thanks to everyone who participated in the discussion on this topic. I tried to collect all ideas into a JIRA task: https://mariadb.atlassian.net/browse/MDEV-7628 Please have a look. Thanks.

1 0

[Maria-developers] Contributing in Support for GTID in mysqlbinlog for GSoC'15
by Rohit Kashyap 24 Feb '15

24 Feb '15

HI Kristian, I am Rohit Kashyap, I am currently working on MDEV-7569 and recently came over to your post on Support for GTID in mysqlbinlog [MDEV-4989] I would like to ask you for guidance and leads on this so that I can take it up as my GSoC'15 Project under MariaDB. -- Kind Regards, Rohit

2 3

[Maria-developers] auth_socket/unix_socket auth plugin naming incompatibility with Percona Server
by John Leach 23 Feb '15

23 Feb '15

Hi, I just tested a switch from Percona Server 5.6 to MariaDB 10.0.16 and hit a problem with socket authentication. I had it set up to auth root using the auth_socket plugin, but when I switched to MariaDB I could no longer login as root. I get this error from the client: ERROR 1524 (HY000): Plugin 'auth_socket' is not loaded Anyway, after I bunch of investigation, I found that the plugin used to expose itself as socket_peercred but was renamed due to a conflict and Percona and MariaDB chose different names to fix it. Percona renamed it to auth_socket, matching the actual library filename auth_socket.so and MariaDB chose unix_socket, but keeping the filename auth_socket.so: https://github.com/MariaDB/server/commit/b8b7b4eb6bef26d05257272be02674ae55… https://github.com/percona/percona-server/commit/91a2afcbcba8af28d2f10f8083… This isn't great, but it's made worse because the plugin is successfully loaded in both cases (because the filename is auth_socket.so) and no errors are reported in the logs, but the plugin just exposes itself internally using a different name so reports that auth_socket isn't loaded in MariaDB. I fixed it by starting mysql with skip-grant-tables and running: update mysql.user set plugin='unix_socket' where plugin='auth_socket'; but that alone doesn't work, because MariaDB doesn't know that unix_socket is provided by auth_socket.so: ERROR 1524 (HY000): Plugin 'unix_socket' is not loaded So I then added this to the config file, which fixed it: plugin-load=unix_socket=auth_socket.so Any thoughts on what to do here? Can the plugin be made to recognise both names, so other users don't end up in this situation? I presume there would need to be both auth_socket.so and unix_socket.so. I also presume Percona would need to provide the same, to help those moving from MariaDB to Percona. Thanks, John. -- https://www.brightbox.com

2 4

[Maria-developers] (no subject)
by Rohit Kashyap 22 Feb '15

22 Feb '15

HI Kristian, I am Rohit Kashyap, I am currently working on MDEV-7569 and recently came over to your post on Support for GTID in mysqlbinlog [MDEV-4989] I would like to ask you for guidance and leads on this so that I can take it up as my GSoC'15 Project under MariaDB. -- Kind Regards, Rohit

1 0

[Maria-developers] Suggestion for MariaDB Workbench
by Rohit Kashyap 22 Feb '15

22 Feb '15

Hi, Based on the following posts http://stackoverflow.com/questions/22616861/can-i-use-mysql-workbench-to-cr… https://mariadb.com/kb/en/mariadb/guiworkbench-for-mariadb-aria/ https://mariadb.com/kb/en/mariadb/graphical-clients/ Can we build a Standalone GUI Client for MariaDB. -- Kind Regards, Rohit

1 0

[Maria-developers] Google Summer of Code 2015
by Delveri chick 22 Feb '15

22 Feb '15

Hi sergii i have some working knowledge of ldap not much though but I think following your post, it will be great for MariaDb to incorporate an ldap plugin that could be used by organisations running ldap servers and mariadb. For example most large organisations like Google keep information about their workers in a directory service on the servers. Creating users tables to hold this info will take too much time. Managing this table is also a huge task which can also reduce performance due to overpopulation. The ldap plugin will serve as an interface between mariadb and the directory service such that info can be retrieved with ease. The cool stuff with ldap is that if a request is made to the directory service and the requested data is not there, a reference to another directory service that contains it is returned. The Ldap plugin if incorporated into mariadb can be used to authenticate users since in runs directly on the TCT/IP stack. Please request for more details if you need more explanation that will convince mariadb developpers to include this task at GSoc 2015. Best regards Chick

1 0

[Maria-developers] binlog_row_image
by Rasmus Johansson 19 Feb '15

19 Feb '15

Hi, Is anyone familiar with binlog_row_image in MySQL 5.6, would it make sense to add it to MariaDB? I received a request for it where they have a wide table with high write activity and only a few fields are updated for each DML. Apparently binlog_row_image would be efficient in this case. There is also a JIRA issue about binlog_row_image from the MySQL compatibility point of view: https://mariadb.atlassian.net/browse/MDEV-7471 Rasmus -- Rasmus Johansson, VP Engineering MariaDB | t: +358 50 499 9589 | Skype: ratzpo

2 1

Re: [Maria-developers] e91559c: MDEV-7006 MDEV-7007: SET STATEMENT and slow log
by Sergei Golubchik 16 Feb '15

16 Feb '15

Hi, Oleksandr! On Jan 28, Oleksandr Byelkin wrote: > revision-id: e91559cf7f2b19378e9e5d3f72c3a6794a09d1e0 > parent(s): cbc318fcf3680c01dca1320b87f625124a497528 > committer: Oleksandr Byelkin > branch nick: work-maria-10.1-MDEV-6997 > timestamp: 2014-11-26 11:54:29 +0100 > message: > > MDEV-7006 MDEV-7007: SET STATEMENT and slow log > fixed embedded server tests > > old values of SET STATENENT variables now saved in its own Query_arena and restored later Basically, I have two comments: 1. I think it might be kind of expensive to create MEM_ROOT for every SET STATEMENT. And perhaps a user will never need to set-statement these log variables. I don't see a good solution for that. Either we can drop the support for log related variables in SET STATEMENT, basically not using your patch. I wouldn't like that, from a user point of view this is a pretty artificial limitation, he doesn't care about memroots. Or we can only create memroot for log related variables and put other variables in the statement memroot, which also means restoring values in two steps. Seems like too complex for a solution. A compromise solution would be to do almost like in your patch, but not to free memroot after every statement. That is, a memroot is created once, for the first SET STATEMENT. At the end of the statement you only MY_MARK_BLOCKS_FREE or MY_KEEP_PREALLOC. Then the next SET STATEMENT wouldn't need to allocate that much. Not perfect, but might do as a tradeoff. Or, perhaps you can suggest a better solution. 2. I didn't quite like that you've added restore_set_statement_var, reset_arena_for_set_stmt, free_arena_for_set_stmt, etc everywhere. I'd prefer you to add them to one function which is called from all these places. Like, there must be some cleanup-after-statement function that you should be able to use. > diff --git a/mysql-test/t/set_statement.test b/mysql-test/t/set_statement.test > index a658071..108c1a3 100644 > --- a/mysql-test/t/set_statement.test > +++ b/mysql-test/t/set_statement.test > @@ -995,6 +985,57 @@ set global general_log=0; > set statement lock_wait_timeout=1 for select @@lock_wait_timeout; > set global general_log=@save_general_log; > > +--echo # MDEV-7006 MDEV-7007: SET statement and slow log > + > +set @save_long_query_time= @@long_query_time; > +set @save_slow_query_log= @@slow_query_log; > +set @save_log_output= @@log_output; > + > +set statement long_query_time=default for select @@long_query_time; > +set statement log_slow_filter=default for select @@log_slow_filter; > +set statement log_slow_verbosity=default for select @@log_slow_verbosity; > +set statement log_slow_rate_limit=default for select @@log_slow_rate_limit; > +set statement slow_query_log=default for select @@slow_query_log; > + > +truncate table mysql.slow_log; > +set slow_query_log= 1; > +set global log_output='TABLE'; > + > +select sql_text from mysql.slow_log; > +set @@long_query_time=0.01; > +--echo #should be written > +select sleep(0.1); > +set @@long_query_time=@save_long_query_time; > +select sql_text from mysql.slow_log; > +--echo #--- > +--echo #should be written > +set statement long_query_time=0.01 for select sleep(0.1); > +select sql_text from mysql.slow_log; Okay, I hope it'll work, but please do try it in a separate branch in buildbot. all these timing-related tests have proven to be very fragile, so I've learned to be very cautious about these stuff. even in test that looks safe to me :) > +--echo #--- > +set @@long_query_time=0.01; > +--echo #should NOT be written > +set statement slow_query_log=0 for select sleep(0.1); > +set @@long_query_time=@save_long_query_time; > +select sql_text from mysql.slow_log; > +--echo #--- > +--echo #should be NOT written > +set statement long_query_time=0.01,log_slow_filter='full_scan' for select sleep(0.1); > +select sql_text from mysql.slow_log; > +--echo #--- > +--echo #should be NOT written > +set statement long_query_time=0.01,log_slow_rate_limit=9999 for select sleep(0.1); > +select sql_text from mysql.slow_log; > +--echo #--- > +# > +# log_slow_verbosity is impossible to check because results are not written > +# in TABLE mode > +# > + > +set global log_output= @save_log_output; > +set @@slow_query_log= @save_slow_query_log; > +set @@long_query_time= @save_long_query_time; > + > + > # > # Prohibited Variables > # > diff --git a/sql/sql_lex.cc b/sql/sql_lex.cc > index 6432e19..08094ce 100644 > --- a/sql/sql_lex.cc > +++ b/sql/sql_lex.cc > @@ -4235,6 +4236,53 @@ int LEX::print_explain(select_result_sink *output, uint8 explain_flags, > return res; > } > > +void LEX::set_arena_for_set_stmt(Query_arena *backup) > +{ > + DBUG_ENTER("LEX::set_arena_for_set_stmt"); > + DBUG_ASSERT(arena_for_set_stmt== 0); > + MEM_ROOT *mem_root= new MEM_ROOT(); > + if (!(mem_root)) > + DBUG_VOID_RETURN; > + init_sql_alloc(mem_root, ALLOC_ROOT_MIN_BLOCK_SIZE, 0, > + MYF(MY_THREAD_SPECIFIC)); > + if (!(arena_for_set_stmt= new Query_arena(mem_root, > + Query_arena::STMT_INITIALIZED))) > + DBUG_VOID_RETURN; 1. allocate a new memroot for every SET STATEMENT? 2. no error reporting? > + DBUG_PRINT("info", ("mem_root: 0x%lx arena: 0x%lx", > + (ulong) mem_root, (ulong) arena_for_set_stmt)); > + thd->set_n_backup_active_arena(arena_for_set_stmt, backup); > + DBUG_VOID_RETURN; > +} > + > + > +void LEX::reset_arena_for_set_stmt(Query_arena *backup) > +{ > + DBUG_ENTER("LEX::reset_arena_for_set_stmt"); > + DBUG_ASSERT(arena_for_set_stmt); > + thd->restore_active_arena(arena_for_set_stmt, backup); > + DBUG_PRINT("info", ("mem_root: 0x%lx arena: 0x%lx", > + (ulong) arena_for_set_stmt->mem_root, > + (ulong) arena_for_set_stmt)); > + DBUG_VOID_RETURN; > +} > + > + > +void LEX::free_arena_for_set_stmt() > +{ > + DBUG_ENTER("LEX::free_arena_for_set_stmt"); > + if (!arena_for_set_stmt) > + return; > + DBUG_PRINT("info", ("mem_root: 0x%lx arena: 0x%lx", > + (ulong) arena_for_set_stmt->mem_root, > + (ulong) arena_for_set_stmt)); > + arena_for_set_stmt->free_items(); > + free_root(arena_for_set_stmt->mem_root, MYF(0)); > + delete(arena_for_set_stmt->mem_root); > + delete(arena_for_set_stmt); Eh... The arena is allocated in the memroot. I don't think you can free the memroot before the arena. Probably something like this: MEM_ROOT *memroot= arena_for_set_stmt->mem_root; delete arena_for_set_stmt; free_root(memroot, MYF(0)); delete memroot; > + arena_for_set_stmt= 0; > + DBUG_VOID_RETURN; > +} > + > void LEX::restore_set_statement_var() > { > DBUG_ENTER("LEX::restore_set_statement_var"); > @@ -4243,7 +4291,9 @@ void LEX::restore_set_statement_var() > DBUG_PRINT("info", ("vars: %d", old_var_list.elements)); > sql_set_variables(thd, &old_var_list, false); > old_var_list.empty(); > + free_arena_for_set_stmt(); > } > + DBUG_ASSERT(!is_arena_for_set_stmt()); the indentation is broken like this in many parts of the patch. May be that's because you've forwarded it with your MUA... > DBUG_VOID_RETURN; > } > > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index 5af700b..ae831d0 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -1956,6 +1958,7 @@ bool dispatch_command(enum enum_server_command command, THD *thd, > > /* Check that some variables are reset properly */ > DBUG_ASSERT(thd->abort_on_warning == 0); > + thd->lex->restore_set_statement_var(); too bad you had to put these restore_set_statement_var, reset_arena_for_set_stmt, free_arena_for_set_stmt, etc everywhere explicitly. > DBUG_RETURN(error); > } > Regards, Sergei

2 2

[Maria-developers] Fwd: Contributing in MariaDB Project
by Rohit Kashyap 13 Feb '15

13 Feb '15

Hi, I am Rohit from NIT Patna, India. A Engineering Student and contributor in MySQL Community, approved by Oracle. You guys are doing great things at Team Maria DB. Kudos for that. I would like to start and contribute in the Maria project, and would like to ask for guiding in the same, with code base and introductory Bugs to prove myself. -- Kind Regards, Rohit Freenode: rkgudboy -- Kind Regards, Rohit

2 5

Re: [Maria-developers] Row-based replication of old DECIMAL to new DECIMAL
by Sergei Golubchik 13 Feb '15

13 Feb '15

Hi, Alexander! On Dec 22, Alexander Barkov wrote: > Hi Sergei, Kristian, > > I'm looking at: > > MDEV-7268 Column of table cannot be converted from type 'decimal(0,?)' > to type ' 'decimal(10,7)' > > This bug cannot be fixed in general case, because the old DECIMAL data > type does not write its metadata into the binary log. > > I suggest we don't fix replication of old DECIMAL > (neither binlogging, nor slave-side). I think that's reasonable. But then CHECK TABLE ... FOR UPGRADE should issue a warning for old DECIMAL columns. > Instead, we fix "ALTER TABLE ... FORCE" (and thus mysql_upgrade) > to force changing old DECIMAL to new DECIMAL. > Currently, "ALTER TABLE...FORCE" preserve old DECIMAL. > > Not sure which version is best to fix in. > The complainer had problems with 5.5. I don't know, I'd say 10.0. For the complainer there's a workaround - I'm sure you can come up with an ALTER TABLE that changes columns from old to new DECIMAL, may be something like ALTER TABLE xxx MODIFY COLUMN yyy DECIMAL(....) Regards, Sergei

7 15