- developers - lists.mariadb.org

[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

[Maria-developers] Crash during configure without development SSL libraries installed
by Vicențiu Ciorbaru 12 Feb '15

12 Feb '15

Hi Sergei! The following error occurs while trying to configure MariaDB 10.0 using the command "cmake ." without the development SSL libraries installed. I've attached the patch to fix the errors. ERROR LOG: ---------------------- CMake Error at cmake/ssl.cmake:162 (FILE): file STRINGS file "/home/vicentiu/Workspace/MariaDB/10.0/OPENSSL_INCLUDE_DIR-NOTFOUND/openssl/opensslv.h" cannot be read. Call Stack (most recent call first): CMakeLists.txt:356 (MYSQL_CHECK_SSL) Regards, Vicentiu

2 1

[Maria-developers] Fwd: MDEV-6838 Using too big key for internal temp tables
by Vicențiu Ciorbaru 12 Feb '15

12 Feb '15

+ CC maria-developers Hi Sergei! I have attached the diff for MDEV-6838. Let me know your thoughts on it. The test case now fails without the patch and passes with the patch on both 5.5 and 10.0. Sergey Petrunia is alright with the patch. Regards, Vicențiu

2 2

[Maria-developers] Interest in Contributing to MariaDB and participation in GSoC 2015
by Tekang Check 11 Feb '15

11 Feb '15

Hello, I am Tekang Mengwe, a third year Accounting student at the University of Buea. I am interested in contributing code to MariaDB and participating in the 2015 round of the Google Summer of Code. While looking at the projects. I'm interested in Database replication and would love to do some work in this respect. I am proficient in C/C++ and code as a hobby. I will greatly appreciate any assistance in this respect. Regards, Tekang

6 7

[Maria-developers] Debian and reproducible builds errors for MariaDB
by Otto Kekäläinen 06 Feb '15

06 Feb '15

Hello! Can somebody please help me with this, preferrably send me a patch I can add to the Debian MariaDB 10.0 packaging tree? Debian has this new test suite for reproducible builds: https://reproducible.debian.net/reproducible.html MariaDB has notes while MySQL is OK (no notes): https://reproducible.debian.net/index_notes.html MariaDB should be at least as good as MySQL, right? MariaDB notes: https://reproducible.debian.net/rb-pkg/mariadb-10.0.html The errors in the build log https://reproducible.debian.net/rbuild/mariadb-10.0_10.0.16-1.rbuild.log look like this: /tmp/buildd/mariadb-10.0-10.0.16/storage/connect/ha_connect.cc:174:46: error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time] char compver[]= "Version 1.03.0006 " __DATE__ " " __TIME__; ^ /tmp/buildd/mariadb-10.0-10.0.16/storage/connect/ha_connect.cc:174:60: error: macro "__TIME__" might prevent reproducible builds [-Werror=date-time] char compver[]= "Version 1.03.0006 " __DATE__ " " __TIME__; ^ Could somebody look into this and send me a patch that fixes it? (and commit the same patch upstream, ofcourse) PS. While searching the log for errors I also noticed these unrelated ones, how do we fix them?: /tmp/buildd/mariadb-10.0-10.0.16/builddir /tmp/buildd/mariadb-10.0-10.0.16/builddir/storage/perfschema /tmp/buildd/mariadb-10.0-10.0.16/builddir/storage/perfschema/CMakeFiles/perfschema.dir/DependInfo.cmake --color= troff: fatal error: can't find macro file m /tmp/buildd/mariadb-10.0-10.0.16/builddir /tmp/buildd/mariadb-10.0-10.0.16/builddir/storage/federatedx /tmp/buildd/mariadb-10.0-10.0.16/builddir/storage/federatedx/CMakeFiles/federatedx.dir/DependInfo.cmake --color= troff: fatal error: can't find macro file m

2 1