- developers - lists.mariadb.org

Re: [Maria-developers] MariaDB release help
by Kristian Nielsen 08 Sep '09

08 Sep '09

Hakan Kuecuekyilmaz <hakan(a)askmonty.org> writes: > Where do you need some help for our release? Looking at http://askmonty.org/wiki/index.php/MariaDB_5.1_TODO, seems it is currently mostly the mysql-5.1.38 merge. One thing that would be useful is to try some additional testing on top of what is already in Buildbot, as there is quite a lot missing... some of this might be better done after the merge is pushed though, but you could start preparing. Maybe you could check what additional test suites/tools are already available that could be used? Stuff like unit tests, mysql-test-run --ps-protocol, additional test suites... One thing in particular is to prepare to test the actual release. Releases are built in a two-step process, first build a source tarball, and then build the binaries from those sources. Buildbot builds directly from a bzr checkout. And Binaries are run from the installed location, while Buildbot runs the tests from the build directory. It would be really embarrassing if some major part of our binaries were released completely broken due to some file or something not being included and no testing at all done :-(. So we could use some tools to test stuff like this. Eventually we want this in Buildbot of course. Concrete suggestion: 1. Testing on installed mysqld. Run `BUILD/compile-dist && make dist`. Unpack those sources and run `./configure <options> && make && make install`. Run `make clean` (to catch bad references into build dir). Then run the testsuite on the installed mysqld. 2. What we used to call "smoke test" at MySQL: Build a binary package, then install it on some machine and see that it can start and stop. Basically testing the package stuff (directory structure, mysqld_safe, ...) which is not covered by the test suite. See http://askmonty.org/wiki/index.php/MariaDB::PackageBuild for how packages are built currently. > My idea to work on and look into it: Currently we have around 10 test > failures on Mac/PPC. If you want, I can start looking into those > failures. Where should we report failing tests? I would like to open > a bug for each test failure. Currently we seem to be using Launchpad for bugs. However, it does not sound all that useful to blindly report one bug per failure. Probably some of them are related with same root cause. If you can identify those root causes, then one bug each makes sense (maybe this is what you meant). Otherwise a single bug probably, just noting that someone needs to look into it when time is available. - Kristian.

2 1

[Maria-developers] [Branch ~maria-captains/maria/5.1] Rev 2730: Fix that thd->query_plan_flags was not initialised prior to executing non-query commands
by noreply＠launchpad.net 07 Sep '09

07 Sep '09

------------------------------------------------------------ revno: 2730 committer: knielsen(a)knielsen-hq.org branch nick: work timestamp: Mon 2009-09-07 15:13:58 +0200 message: Fix that thd->query_plan_flags was not initialised prior to executing non-query commands (also fixes a Valgrind warning in Buildbot). modified: sql/sql_parse.cc -- lp:maria https://code.launchpad.net/~maria-captains/maria/5.1 Your team Maria developers is subscribed to branch lp:maria. To unsubscribe from this branch go to https://code.launchpad.net/~maria-captains/maria/5.1/+edit-subscription.

1 0

[Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2730)
by knielsen＠knielsen-hq.org 07 Sep '09

07 Sep '09

#At lp:maria 2730 knielsen(a)knielsen-hq.org 2009-09-07 Fix that thd->query_plan_flags was not initialised prior to executing non-query commands (also fixes a Valgrind warning in Buildbot). modified: sql/sql_parse.cc === modified file 'sql/sql_parse.cc' --- a/sql/sql_parse.cc 2009-09-03 14:05:38 +0000 +++ b/sql/sql_parse.cc 2009-09-07 13:13:58 +0000 @@ -975,6 +975,7 @@ bool dispatch_command(enum enum_server_c the slow log only if opt_log_slow_admin_statements is set. */ thd->enable_slow_log= TRUE; + thd->query_plan_flags= QPLAN_INIT; thd->lex->sql_command= SQLCOM_END; /* to avoid confusing VIEW detectors */ thd->set_time(); VOID(pthread_mutex_lock(&LOCK_thread_count));

1 0

Re: [Maria-developers] [Branch ~maria-captains/maria/5.1] Rev 2726: Updated documentation files to reflect MariaDB and not the Maria storage engine or MySQL
by Kristian Nielsen 07 Sep '09

07 Sep '09

noreply(a)launchpad.net writes: > Merge authors: > Michael Widenius (monty) > ------------------------------------------------------------ > revno: 2726 [merge] > committer: Michael Widenius <monty(a)mysql.com> > branch nick: maria > timestamp: Thu 2009-09-03 17:56:46 +0300 > message: > Updated documentation files to reflect MariaDB and not the Maria storage engine or MySQL > Added (rewritten) patch from Percona to get extended statistics in slow.log: > === modified file 'sql/log.cc' > --- sql/log.cc 2009-04-25 10:05:32 +0000 > +++ sql/log.cc 2009-09-03 14:05:38 +0000 > @@ -987,6 +987,17 @@ > query_length= command_name[thd->command].length; > } > > + if (!query_length) > + { > + /* > + Not a real query; Reset counts for slow query logging > + (QQ: Wonder if this is really needed) > + */ > + thd->sent_row_count= thd->examined_row_count= 0; > + thd->query_plan_flags= QPLAN_INIT; > + thd->query_plan_fsort_passes= 0; > + } This part of the patch makes me wonder. Isn't this dead code? Just above, the code does this: if (!query) { is_command= TRUE; query= command_name[thd->command].str; query_length= command_name[thd->command].length; } So the above part of the patch will only run when query!=0 && query_length==0. Can this ever happen? If not, the code should probably be removed. If so, maybe add a comment explaining when this happens (and change it to be in an else {} clause of the if statement just before it). - Kristian.

1 0

[Maria-developers] No more compiler warnings in lp:maria!
by Kristian Nielsen 07 Sep '09

07 Sep '09

While the subject of this mail is not quite true yet, I'm happy to announce progress on this project that Monty and I have been discussing for some time. Basically, compiler warnings are very useful to catch a number of bugs in our sources. This has been proven time and time again. However, to do this effectively, we need to keep a state where there are no compiler warnings in the main tree, so that we can detect any new warnings introduced by patches and fix any problems accordingly. With my latest push this morning, the Buildbot compiles on builders hardy-amd64-valgrind and work-amd64-valgrind are now completely free of warnings. This means any new patches must be also clean from warnings on these hosts. Any newly introduced warnings should be fixed ASAP. There are still some compiler warnings left on the other hosts, which would be really good to also eliminate. Any help in this direction would be greatly appreciated. There are a few compiler warnings that could not be fixed meaningfully in the source for various reasons. These warnings are instead suppressed from Buildbot using the file support-files/compiler_warnings.supp. Over time we should strive to remove things from this file. However, we should not make stupid changes to the code just to make a silly compiler happy. I also added to the tree this script: support-files/ccfilter This can be used locally by developers to apply support-files/compiler_warnings.supp to the output of a local build, just like Buildbot suppresses compiler warnings from this file. This is useful to check that new patches are warning-free before pushing. There are some comments at the start of the script describing usage. But basically, run ./configure with CC="ccfilter gcc" CXX="ccfilter gcc" Then the suppressed compiler warnings will be removed from the compiler output. And setting the FAILONWARNING environment variable can be used to cause a build failure on non-suppressed warning (similar to -Wall, but heeding support-files/compiler_warnings.supp). - Kristian.

1 0

[Maria-developers] [Branch ~maria-captains/maria/5.1] Rev 2729: Fix compiler warnings.
by noreply＠launchpad.net 07 Sep '09

07 Sep '09

------------------------------------------------------------ revno: 2729 committer: knielsen(a)knielsen-hq.org branch nick: work timestamp: Mon 2009-09-07 09:12:38 +0200 message: Fix compiler warnings. modified: sql/opt_table_elimination.cc -- lp:maria https://code.launchpad.net/~maria-captains/maria/5.1 Your team Maria developers is subscribed to branch lp:maria. To unsubscribe from this branch go to https://code.launchpad.net/~maria-captains/maria/5.1/+edit-subscription.

1 0

[Maria-developers] bzr commit into MariaDB 5.1, with Maria 1.5:maria branch (knielsen:2729)
by knielsen＠knielsen-hq.org 07 Sep '09

07 Sep '09

#At lp:maria 2729 knielsen(a)knielsen-hq.org 2009-09-07 Fix compiler warnings. modified: sql/opt_table_elimination.cc === modified file 'sql/opt_table_elimination.cc' --- a/sql/opt_table_elimination.cc 2009-09-01 21:41:16 +0000 +++ b/sql/opt_table_elimination.cc 2009-09-07 07:12:38 +0000 @@ -1802,16 +1802,16 @@ void Dep_analysis_context::dbug_print_de eq_mod->expr->print(&str, QT_ORDINARY); if (eq_mod->field) { - fprintf(DBUG_FILE, " equality%d: %s -> %s.%s\n", - eq_mod - equality_mods, + fprintf(DBUG_FILE, " equality%ld: %s -> %s.%s\n", + (long)(eq_mod - equality_mods), str.c_ptr(), eq_mod->field->table->table->alias, eq_mod->field->field->field_name); } else { - fprintf(DBUG_FILE, " equality%d: multi-equality", - eq_mod - equality_mods); + fprintf(DBUG_FILE, " equality%ld: multi-equality", + (long)(eq_mod - equality_mods)); } } fprintf(DBUG_FILE,"\n");

1 0

[Maria-developers] Progress (by Knielsen): mysqlbinlog: remove undesired effects of format description binlog statement (50)
by worklog-noreply＠askmonty.org 07 Sep '09

07 Sep '09

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: mysqlbinlog: remove undesired effects of format description binlog statement CREATION DATE..: Mon, 17 Aug 2009, 14:12 SUPERVISOR.....: Monty IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 50 (http://askmonty.org/worklog/?tid=50) VERSION........: Server-9.x STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 2 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: -=-=(Knielsen - Mon, 07 Sep 2009, 10:06)=-=- Research worklog, bugs, and existing server code. Worked 2 hours and estimate 0 hours remain (original estimate increased by 2 hours). -=-=(Psergey - Mon, 17 Aug 2009, 14:13)=-=- Dependency created: 39 now depends on 50 -=-=(Psergey - Mon, 17 Aug 2009, 14:13)=-=- High-Level Specification modified. --- /tmp/wklog.50.old.11389 2009-08-17 14:13:05.000000000 +0300 +++ /tmp/wklog.50.new.11389 2009-08-17 14:13:05.000000000 +0300 @@ -1 +1,14 @@ +First item +---------- +AFAIU what needs to be done is: +1. record a source server version (it is in the first binlog event). +2. don't emit a BINLOG statement if the recorded version number is 5.0.x or + below. + +and we'll get a 5.0-applicable binlog. + +Second item +----------- +One question that one needs to sort out before disabling server_id change is +why it was put there in the first place? Should it be always removed? DESCRIPTION: According to complaints in BUG#46640: 1. mysqlbinlog will emit a 5.0-incompatible "format description binlog statement" even when reading a binary log that was produced by 5.0. This will cause an error when one tires to apply mysqlbinlog output to a 5.0.x server. 2. When one applies "format description binlog statement" at the slave, it will change the slave's server_id when applied. This WL is to fix these issues. HIGH-LEVEL SPECIFICATION: First item ---------- AFAIU what needs to be done is: 1. record a source server version (it is in the first binlog event). 2. don't emit a BINLOG statement if the recorded version number is 5.0.x or below. and we'll get a 5.0-applicable binlog. Second item ----------- One question that one needs to sort out before disabling server_id change is why it was put there in the first place? Should it be always removed? ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] Progress (by Knielsen): mysqlbinlog: remove undesired effects of format description binlog statement (50)
by worklog-noreply＠askmonty.org 07 Sep '09

07 Sep '09

----------------------------------------------------------------------- WORKLOG TASK -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- TASK...........: mysqlbinlog: remove undesired effects of format description binlog statement CREATION DATE..: Mon, 17 Aug 2009, 14:12 SUPERVISOR.....: Monty IMPLEMENTOR....: COPIES TO......: CATEGORY.......: Server-RawIdeaBin TASK ID........: 50 (http://askmonty.org/worklog/?tid=50) VERSION........: Server-9.x STATUS.........: Un-Assigned PRIORITY.......: 60 WORKED HOURS...: 2 ESTIMATE.......: 0 (hours remain) ORIG. ESTIMATE.: 0 PROGRESS NOTES: -=-=(Knielsen - Mon, 07 Sep 2009, 10:06)=-=- Research worklog, bugs, and existing server code. Worked 2 hours and estimate 0 hours remain (original estimate increased by 2 hours). -=-=(Psergey - Mon, 17 Aug 2009, 14:13)=-=- Dependency created: 39 now depends on 50 -=-=(Psergey - Mon, 17 Aug 2009, 14:13)=-=- High-Level Specification modified. --- /tmp/wklog.50.old.11389 2009-08-17 14:13:05.000000000 +0300 +++ /tmp/wklog.50.new.11389 2009-08-17 14:13:05.000000000 +0300 @@ -1 +1,14 @@ +First item +---------- +AFAIU what needs to be done is: +1. record a source server version (it is in the first binlog event). +2. don't emit a BINLOG statement if the recorded version number is 5.0.x or + below. + +and we'll get a 5.0-applicable binlog. + +Second item +----------- +One question that one needs to sort out before disabling server_id change is +why it was put there in the first place? Should it be always removed? DESCRIPTION: According to complaints in BUG#46640: 1. mysqlbinlog will emit a 5.0-incompatible "format description binlog statement" even when reading a binary log that was produced by 5.0. This will cause an error when one tires to apply mysqlbinlog output to a 5.0.x server. 2. When one applies "format description binlog statement" at the slave, it will change the slave's server_id when applied. This WL is to fix these issues. HIGH-LEVEL SPECIFICATION: First item ---------- AFAIU what needs to be done is: 1. record a source server version (it is in the first binlog event). 2. don't emit a BINLOG statement if the recorded version number is 5.0.x or below. and we'll get a 5.0-applicable binlog. Second item ----------- One question that one needs to sort out before disabling server_id change is why it was put there in the first place? Should it be always removed? ESTIMATED WORK TIME ESTIMATED COMPLETION DATE ----------------------------------------------------------------------- WorkLog (v3.5.9)

1 0

[Maria-developers] Documentation for new features in MariaDB
by Kristian Nielsen 07 Sep '09

07 Sep '09

We are starting to add new features to MariaDB (that are not in MySQL), including user-visible features. I think we need to decide now how we will handle keeping documentation for these new features. There is an open issue about the MySQL documentation being non-free, and whether we can do anything about it. But until this is resolved, on way or the other, we still need somewhere to write documentation. I think it is mainly about setting up a repository somewhere and start adding text. The important thing now is to get the content there, the presentation can be enhanced later. So we would have a manual "differences between MariaDB and MySQL" or something. If we have the content we can use it later in whatever form we need, if we omit adding the content now it is going to be really hard to figure out everything that's missing in a year or two. Daniel, any suggestions for what format to use? Can we use the same format as the MySQL documentation (is it docbook or something, can't remember)? Also, until we get procedures like at MySQL/Sun for a documentation team that ensures all features and bug fixes get documented, I think it is the responsibility of each developer that documentation gets added in the right place. I would really like to see us keeping the up the standard that everything in MySQL (now MariaDB) is documented. - Kristian.

7 22