- developers - lists.mariadb.org

[Maria-developers] MariaDB 5.2.7
by Daniel Bartholomew 15 Jun '11

15 Jun '11

Hello all, Just writing to let you know that MariaDB 5.2.7 is now almost completely mirrored worldwide, so I've activated the downloads page and the release notes and changelog. Here are the links: http://kb.askmonty.org/en/mariadb-527-release-notes http://kb.askmonty.org/en/mariadb-527-changelog http://downloads.askmonty.org/mariadb/5.2.7/ If any of you have a moment, please review the release notes and make (or suggest) any necessary changes. I tried to incorporate everything that I was told about this release, but I may have missed something. Now turning things over to the community team to announce and promote. Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

1 0

[Maria-developers] Preparing to release MariaDB 5.2.7
by Daniel Bartholomew 14 Jun '11

14 Jun '11

Monty, I saw your note about the new MariaDB 5.2.7 release being ready, but it looks like the "mariadb-5.2.7" tag has not been added to the 5.2 tree on launchpad. Can you or one of the other developers add it? I need the tag as part of my process for creating the changelog. Apart from that, I just need to determine which buildbot build is the correct one. Kristian, You sent me some instructions a while back for how to do this but I can't remember them. I guess you've spoiled me by usually just telling me the build number. :) Can you send the instructions to me again? Thanks. -- Daniel Bartholomew MariaDB - http://mariadb.org Monty Program - http://montyprogram.com AskMonty Knowledgebase - http://kb.askmonty.org

3 4

[Maria-developers] tmp-table-tests MariaDB 5.2.6 vs. 5.5.12 vs. 5.1.57
by erkan yanar 09 Jun '11

09 Jun '11

Moin, I did some tmp-table tests. As it is told MariaDB is faster on tmp-tables because of the Aria-Engine. Therefore Ive got 3 Severs running: onyx:/data/dbod # for i in 6051 6053 6060; do mysql -u erkan -h 10.255.128.4 -P $i -e 'select version()'; done +------------+ | version() | +------------+ | 5.5.12-log | +------------+ +-------------------+ | version() | +-------------------+ | 5.2.6-MariaDB-log | +-------------------+ +------------+ | version() | +------------+ | 5.1.57-log | key_buffer_size is 16MB. For MariaDB there is also: mysql> show global variables like 'aria_pagecache_buffer_size'; +----------------------------+----------+ | Variable_name | Value | +----------------------------+----------+ | aria_pagecache_buffer_size | 16777216 | +----------------------------+----------+ To provoke tmp-tables I did: onyx:/data/dbod # for i in 6051 6053 6060; do mysql -u erkan -h 10.255.128.4 -P $i -e 'show global variables like "tmp_table_size"'; done +----------------+-------+ | Variable_name | Value | +----------------+-------+ | tmp_table_size | 1024 | +----------------+-------+ +----------------+-------+ | Variable_name | Value | +----------------+-------+ | tmp_table_size | 1024 | +----------------+-------+ +----------------+-------+ | Variable_name | Value | +----------------+-------+ | tmp_table_size | 1024 | +----------------+-------+ We got two tables: mysql> desc sort_id; +-------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+-------+ | id | int(11) | YES | | NULL | | +-------+---------+------+-----+---------+-------+ 1 row in set (0.00 sec) mysql> desc sort_1; +-------+---------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+---------+------+-----+---------+-------+ | id | int(11) | YES | | NULL | | | tea | text | YES | | NULL | | +-------+---------+------+-----+---------+-------+ 2 rows in set (0.00 sec) With 10000 Rows each. Tests: onyx:/var/tmp # for i in 6051 6053 6060; do mysqlslap -u erkan -P $i -h 10.255.128.4 --create-schema=sbtest -q "SELECT * from sbtest.sort_1 group by id;" --number-of-queries=20 -i 3; done Benchmark [[5.5.12]] Average number of seconds to run all queries: 1.803 seconds Minimum number of seconds to run all queries: 1.791 seconds Maximum number of seconds to run all queries: 1.826 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[MariaDB]] Average number of seconds to run all queries: 5.547 seconds Minimum number of seconds to run all queries: 5.542 seconds Maximum number of seconds to run all queries: 5.556 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[5.1.57]] Average number of seconds to run all queries: 1.605 seconds Minimum number of seconds to run all queries: 1.603 seconds Maximum number of seconds to run all queries: 1.606 seconds Number of clients running queries: 1 Average number of queries per client: 20 onyx:/var/tmp # for i in 6051 6053 6060; do mysqlslap -u erkan -P $i -h 10.255.128.4 --create-schema=sbtest -q "SELECT * from sbtest.sort_id group by id;" --number-of-queries=20 -i 3; done Benchmark [[5.5.12]] Average number of seconds to run all queries: 1.146 seconds Minimum number of seconds to run all queries: 1.135 seconds Maximum number of seconds to run all queries: 1.170 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[MariaDB]] Average number of seconds to run all queries: 4.359 seconds Minimum number of seconds to run all queries: 4.352 seconds Maximum number of seconds to run all queries: 4.366 seconds Number of clients running queries: 1 Average number of queries per client: 20 Benchmark [[5.1.57]] Average number of seconds to run all queries: 1.049 seconds Minimum number of seconds to run all queries: 1.032 seconds Maximum number of seconds to run all queries: 1.068 seconds Number of clients running queries: 1 Average number of queries per client: 20 So MariaDb doesn't perform in this test. So I wonder I did something wrong ... Regards Erkan -- über den grenzen muß die freiheit wohl wolkenlos sein

3 2

[Maria-developers] Reqeust for SHOW FULL FIELDS FROM and virtual tables in MariaDB
by Peter Laursen 06 Jun '11

06 Jun '11

Refer http://kb.askmonty.org/v/virtual-columns - the example CREATE TABLE table1 ( a INT NOT NULL, b VARCHAR(32), c INT AS (a MOD 10) virtual, d VARCHAR(5) AS (LEFT(b,5)) persistent); now SHOW FULL FIELDS FROM table1; Field Type Collation Null Key Default Extra Privileges Comment ------ ----------- ----------------- ------ ------ ------- ------- ------------------------------- ------- a int(11) (NULL) NO (NULL) select,insert,update,references b varchar(32) latin1_swedish_ci YES (NULL) select,insert,update,references c int(11) (NULL) YES (NULL) VIRTUAL select,insert,update,references d varchar(5) latin1_swedish_ci YES (NULL) VIRTUAL select,insert,update,references I request that 'extra' column should return either "PERSISTENT" or " VIRTUAL, PERSISTENT" for column `d`. The reason is that the output from SHOW FULL FIELDS returns an *array* (that will not need to be parsed) as opposite to SHOW CREATE TABLE. Accordingly SHOW FULL FIELDS is much easier to use for an 'unintelligent client' as opposed to an 'intelligent (or ignorant for that sake :-) ) human user to decide on special properties for a column. Peter Webyog

3 4

[Maria-developers] Buildbot failures: Microsecond-related changes break innodb_plugin but not xtradb
by Sergey Petrunya 06 Jun '11

06 Jun '11

Hi! All of the recent 5.3 builds in buildbot have two failures: innodb_plugin.innodb_bug54044 'innodb_plugin' innodb_plugin.innodb_information_schema 'innodb_plugin' The failure happens only with innodb_plugin. XtraDB is fine. I've investigated the first problem. Its cause is in storage/xtradb/handler/ha_innodb.cc:get_innobase_type_from_mysql_type(): - On 2010-08-04, Kristian did a merge from XtraDB in Percona-Server-5.1.47-11 and among everything else pulled in the code that will produce error when the function's argument is Field_null. This seems to be the bugfix for BUG#54044 - On 2011-03-29, Sergei was making fix for lp:743017 in 5.1-micro, switched the function from analyzing field->type() to analyzing field->key_type() and in the process removed the part of code that Kristian has added. For some reason, he did that storage/innodb_plugin and storage/innobase but not to storage/xtradb. - On May, 28th Monty has merged in Sergei's change into 5.3-main and we started to get the failure. I see two problems here: P1: (the apparent one) Sergei's new code doesn't produce error when passed a Field_null object. P2: (less apparent one) Why do we have Microsecond changes in innodb_plugin but not in xtradb? Could there be more fixes missing in a similar way? Sergei, could you please take a look? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

4 4

Re: [Maria-developers] [Commits] Rev 2983: WL#77 - INSTALL PLUGIN * in http://bazaar.launchpad.net/~maria-captains/maria/5.2/
by Vladislav Vaintroub 03 Jun '11

03 Jun '11

> -----Original Message----- > From: commits-bounces(a)mariadb.org [mailto:commits- > bounces(a)mariadb.org] On Behalf Of serg(a)askmonty.org > Sent: Mittwoch, 1. Juni 2011 22:27 > To: commits(a)mariadb.org > Subject: [Commits] Rev 2983: WL#77 - INSTALL PLUGIN * in > http://bazaar.launchpad.net/~maria-captains/maria/5.2/ > > At http://bazaar.launchpad.net/~maria-captains/maria/5.2/ > > ------------------------------------------------------------ > revno: 2983 > revision-id: sergii(a)pisem.net-20110601202627-mcgxt0c3fgxoxxrq > parent: wlad(a)montyprogram.com-20110527170940-vl12r4mni30valsh > committer: Sergei Golubchik <sergii(a)pisem.net> > branch nick: 5.2 > timestamp: Wed 2011-06-01 22:26:27 +0200 > message: > WL#77 - INSTALL PLUGIN * > > new statements INSTALL PLUGIN * SONAME 'xxx' > and UNINSTALL PLUGIN * SONAME 'xxx' Serg, while simplifying "install plugin", do you think it could be even better to get rid of PLUGIN * SONAME altogether and just have INSTALL 'xxx' ? What do you think? Perhaps even more, make shared module/dynamic load library extension optional. It will simplify documentation greatly (so one would not have to mentally translate .so in examples to .dll) . It would also simplify test cases, we can get rid of obligatory --replace_regex /\.dll/.so/ and of $HA_EXAMPLE_SO. Wlad

2 1

[Maria-developers] Buildbot failure in filesort.cc:make_sortkey
by Sergey Petrunya 03 Jun '11

03 Jun '11

Hi Sergei, Current 5.3 fails as follows: http://buildbot.askmonty.org/buildbot/builders/mac-mini-x86-dbg/builds/771/… g++ -DMYSQL_SERVER -DDEFAULT_MYSQL_HOME='"/usr/local/mysql"' -DMYSQL_DATADIR='"/usr/local/mysql/var"' -DSHAREDIR='"/usr/local/mysql/share/mysql"' -DPLUGINDIR='"/usr/local/mysql/lib/mysql/plugin"' -DHAVE_EVENT_SCHEDULER -DHAVE_CONFIG_H -I. -I../include -I../include -I../include -I../regex -I. -I../extra/libevent -Wall -Wextra -Wunused -Wwrite-strings -Wno-strict-aliasing -Werror -DFORCE_INIT_OF_VARS -Wno-unused-parameter -g -Wall -Wextra -Wunused -Wwrite-strings -Wno-uninitialized -Wno-unused-parameter -Wnon-virtual-dtor -felide-constructors -fno-exceptions -fno-rtti -mtune=native -DUNIV_MUST_NOT_INLINE -DEXTRA_DEBUG -DSAFEMALLOC -DPEDANTIC_SAFEMALLOC -O0 -g3 -gdwarf-2 -O2 -Wuninitialized -DFORCE_INIT_OF_VARS -fno-implicit-templates -fno-exceptions -fno-rtti -D_P1003_1B_VISIBLE -DSIGNAL_WITH_VIO_CLOSE -DSIGNALS_DONT_BREAK_READ -DIGNORE_SIGHUP_SIGQUIT -DDONT_DECLARE_CXA_PURE_VIRTUAL -MT debug_sync.o -MD -MP -MF .deps/debug_sync.Tpo -c -o debug_sync.o debug_sync.cc cc1plus: warnings being treated as errors filesort.cc: In function 'void make_sortkey(SORTPARAM*, uchar*, uchar*)': filesort.cc:878: warning: 'value' may be used uninitialized in this function make[3]: *** [filesort.o] Error 1 make[3]: *** Waiting for unfinished jobs.... It is not apparent for me whether this is a real error or not, bazaar history shows that the failure is in your code of MWL#173. Could you please take a look? BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] FYI: MWL#90 pushed into 5.3 main
by Sergey Petrunya 31 May '11

31 May '11

Hello, This is to inform you that today I've pushed MWL#90 into 5.3-main. There was a buildbot run on 5.3-subqueries-mwl90 tree before the push, and it did not show any failures that weren't also present in 5.3-main. The result of my merge has an issue that conceptually it is not a full merge, because MWL#90 code is not able yet to take advantage of the possibily of dynamic choice between IN->EXISTS (which was introduced in MWL#89 which Timour pushed two weeks ago). Adding support for MWL#89 and MWL#90 working together seems easy. Actually, I initially intended to do it while merging, but then decided to do one thing at a time. My further plans are: - look at the open bugs I have - look at making MWL#89 and MWL#90 work together. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] how do I count errors per database user?
by MARK CALLAGHAN 26 May '11

26 May '11

I want to count errors by database user for IS.user_statistics. I have code that does it in my_message_sql but hfisk thinks the counts might be inflated. I don't understand the error reporting framework in MySQL so it is possible that the counts are wrong or count errors and warnings rather than only counting errors. The code below is from my_message_sql and shows where I try to maintain the count. The assignment (thd->is_slave_error= 1) makes me think that an error has occurred by the time I count it. But code that follows has comments about clearing an error or converting an error to a warning. if ((thd= current_thd)) { /* TODO: There are two exceptions mechanism (THD and sp_rcontext), this could be improved by having a common stack of handlers. */ if (thd->handle_error(error, str, MYSQL_ERROR::WARN_LEVEL_ERROR)) DBUG_RETURN(0); { USER_STATS *us= thd_get_user_stats(thd); --------------------------------> added by me my_atomic_add_bigint(&(us->errors_total), 1); --------------------------------> added by me } thd->is_slave_error= 1; // needed to catch query errors during replication /* thd->lex->current_select == 0 if lex structure is not inited (not query command (COM_QUERY)) */ if (thd->lex->current_select && thd->lex->current_select->no_error && !thd->is_fatal_error) { DBUG_PRINT("error", ("Error converted to warning: current_select: no_error %d " "fatal_error: %d", (thd->lex->current_select ? thd->lex->current_select->no_error : 0), (int) thd->is_fatal_error)); } else { if (! thd->main_da.is_error()) // Return only first message { thd->main_da.set_error_status(thd, error, str); } query_cache_abort(&thd->net); } /* If a continue handler is found, the error message will be cleared by the stored procedures code. */ if (thd->spcont && ! (MyFlags & ME_NO_SP_HANDLER) && thd->spcont->handle_error(error, MYSQL_ERROR::WARN_LEVEL_ERROR, thd)) { /* Do not push any warnings, a handled error must be completely silenced. */ DBUG_RETURN(0); } /* When simulating OOM, skip writing to error log to avoid mtr errors */ DBUG_EXECUTE_IF("simulate_out_of_memory", DBUG_RETURN(0);); if (!thd->no_warnings_for_error && !(MyFlags & ME_NO_WARNING_FOR_ERROR)) { /* Suppress infinite recursion if there a memory allocation error inside push_warning. */ thd->no_warnings_for_error= TRUE; push_warning(thd, MYSQL_ERROR::WARN_LEVEL_ERROR, error, str); thd->no_warnings_for_error= FALSE; } } /* When simulating OOM, skip writing to error log to avoid mtr errors */ DBUG_EXECUTE_IF("simulate_out_of_memory", DBUG_RETURN(0);); if (!thd || MyFlags & ME_NOREFRESH) sql_print_error("%s: %s",my_progname,str); /* purecov: inspected */ DBUG_RETURN(0); } -- Mark Callaghan mdcallag(a)gmail.com

2 1

[Maria-developers] More MWL#89 questions
by Sergey Petrunya 25 May '11

25 May '11

Hi Timour, While merging, I also got the following questions: == exclude_expensive_cond == make_cond_for_table()'s exclude_expensive_cond parameter is not used anymore. Was it intentional that you kept it in the code? (minimizing MWL#89's diff size could not be a reason because the diff changes make_cond_for_table signature anyway) == exec_const_cond == The patch introduces JOIN::exec_const_cond. On the other hand, the code already had JOIN::outer_ref_cond which seems to be nearly the same. == join_tab_idx == make_join_select() attaches parts of WHERE/ON clauses to JOIN_TABs. It does so with a help of two functions: 1. make_cond_for_table() 2. make_cond_after_sjm() The first one does make set_join_tab_idx() calls, the second one doesn't. Why? == join_tab_idx #2 === > @@ -7150,24 +7174,27 @@ > there inside the triggers. > */ > { // Check const tables > + join->exec_const_cond= > + make_cond_for_table(thd, cond, > join->const_table_map, > - (table_map) 0, TRUE, FALSE); > + (table_map) 0, MAX_TABLES, FALSE, FALSE); As far as I understand the code, the MAX_TABLES part informs the constant subquery predicate that it will be evaluated O(join_output_records) times, which is not true. This is not the only such case, I see plenty of make_cond_for_table() calls which use MAX_TABLES for join_tab_idx argument, where we can actually tell for certain that the condition will be evaluated much fewer than O(join_output_records) times. BR Sergey -- Sergey Petrunia, Software Developer Monty Program AB, http://askmonty.org Blog: http://s.petrunia.net/blog

2 1