- developers - lists.mariadb.org

[Maria-developers] [GSoC] Week Nine and Ten!
by sriram patil 28 Jul '14

28 Jul '14

Hi All, Following is the blog link about my ninth and tenth week into GSoC. http://goo.gl/N5Le32 Suggestions and/or reviews are welcome! Thanks, Sriram

1 0

[Maria-developers] MDEV-4511 Assertion `scale <= precision' fails on GROUP BY TIMEDIFF with incorrect types
by Alexander Barkov 25 Jul '14

25 Jul '14

Hello Sergei, Please review a new version of the patch for MDEV-4511, it also fixes more crashing problems found, as well as non-crashing problems reported in MDEV-6302 I removed find_num_type() and fix_num_length_and_dec() which were hard to track, and for some Items these methods were erroneously called twice. fix_num_length_and_dec() now only exists as a non-virtual method in Item_sum and Item_udf_func. The patch is for 5.3, but it is still valid for 10.0, as we still have temporal functions with NOT_FIXED_DEC in 10.0. Thanks.

2 3

[Maria-developers] Any plans about starting to use /var/lib/mariadb for data instead of /var/lib/mysql?
by Otto Kekäläinen 24 Jul '14

24 Jul '14

Hello! Does the MariaDB project have any plans about switching the data dir to /var/lib/mariadb in some release? In Debian there has been discussion about separating the binary-incompatible MySQL forks into separate /var/lib/<fork> to ease maintenance and secure data so that purging some packages will not accidentally delete data that another package uses. The thread is named "Discussion on handling 5.6 related matters" and available at http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-July/thread.h… I'd appreciate any guidelines here on what the upstream plans are. The Debian MySQL/MariaDB packaging team willl have an IRC meeting tomorrow at 16:00 UTC and I need to express my opinion on the mattes and what kind of changes I'm willing to do to the MariaDB package. Obviously I'd like to follow upstream as much as possible to keep the delta between Debian and upstream small and thus the maintenance burden reasonable. -- Check out our blog at http://seravo.fi/blog and follow @ottokekalainen

3 2

[Maria-developers] please review mdev-5745 analyze MySQL fix for bug#12368495
by Alexander Barkov 23 Jul '14

23 Jul '14

Hi Serg, please review a patch for mdev-5745. Thanks.

1 0

Re: [Maria-developers] [Commits] 00ed367: MDEV-4262 - P_S discovery
by Sergei Golubchik 22 Jul '14

22 Jul '14

Hi, Sergey! On Jul 07, svoj(a)mariadb.org wrote: > revision-id: 00ed36700addfbce91940223cce4ccd6ee5823a1 > parent(s): f37f19a6c790100cc2ae5f483ba4db34a517f0ae > committer: Sergey Vojtovich > branch nick: 10.1 > timestamp: 2014-07-07 14:32:13 +0400 > message: > > MDEV-4262 - P_S discovery > > Discover P_S tables automatically. > > Most of this patch is code clean-up: > - removed tests and code responsible for P_S tables correctness verification > - always return error from ha_perfschema::create() > - install/upgrade scripts won't create P_S tables anymore Great work, thanks! The patch is pretty much "ok to push", but, first I want to understand why you deleted table_file_summary.cc file. See other minor comments below. > diff --git a/mysql-test/suite/perfschema/include/upgrade_check.inc b/mysql-test/suite/perfschema/include/upgrade_check.inc > index 52d4cfd..1532de8 100644 > --- a/mysql-test/suite/perfschema/include/upgrade_check.inc > +++ b/mysql-test/suite/perfschema/include/upgrade_check.inc > @@ -3,7 +3,6 @@ > # > > --source include/count_sessions.inc > ---error 1 > --exec $MYSQL_UPGRADE --skip-verbose --force > $out_file 2> $err_file > --source include/wait_until_count_sessions.inc The rest of this upgrade_check.inc file does (according to the comment) "Verify that mysql_upgrade complained about the performance_schema" perhaps you should change the comment to say "does not complain" ? > > diff --git a/scripts/mysql_performance_tables.sql b/scripts/mysql_performance_tables.sql > index d495578..3061603 100644 > --- a/scripts/mysql_performance_tables.sql > +++ b/scripts/mysql_performance_tables.sql > @@ -53,1427 +53,3 @@ SET @str = IF(@broken_pfs = 0, @cmd, 'SET @dummy = 0'); > PREPARE stmt FROM @str; > EXECUTE stmt; > DROP PREPARE stmt; Why did you keep the above? I'd think that a simple DROP DATABASE IF EXISTS performance_schema should be enough to replace the whole file. And it could be moved back to mysql_system_tables.sql, so this file could be completely removed. > - > -# > -# From this point, only create the performance schema tables > -# if the server is built with performance schema > -# > - > -set @have_pfs= (select count(engine) from information_schema.engines where engine='PERFORMANCE_SCHEMA' and support != 'NO'); > - > -# > -# TABLE COND_INSTANCES > -# ... > diff --git a/storage/perfschema/pfs_engine_table.cc b/storage/perfschema/pfs_engine_table.cc > index 958a2bd..6f0a363 100644 > --- a/storage/perfschema/pfs_engine_table.cc > +++ b/storage/perfschema/pfs_engine_table.cc > @@ -1440,5 +1319,17 @@ end: > DBUG_RETURN(false); > } > > +int pfs_discover_table_names(handlerton *hton, LEX_STRING *db, > + MY_DIR *dir, hm, no "unused argument" compiler warnings? okay... > + handlerton::discovered_list *result) > +{ > + if (compare_table_names(db->str, PERFORMANCE_SCHEMA_str.str)) > + return 0; > + for (size_t i= 0; i < array_elements(all_shares) - 1; i++) > + result->add_table(all_shares[i]->m_name.str, > + all_shares[i]->m_name.length); > + return 0; > +} > + > /** @} */ > > diff --git a/storage/perfschema/table_file_summary.cc b/storage/perfschema/table_file_summary.cc > deleted file mode 100644 > index 104fa0f..0000000 > --- a/storage/perfschema/table_file_summary.cc > +++ /dev/null > @@ -1,372 +0,0 @@ Why did you remove this file? > -/* Copyright (c) 2008, 2010, Oracle and/or its affiliates. All rights reserved. > - > - This program is free software; you can redistribute it and/or modify > - it under the terms of the GNU General Public License as published by > - the Free Software Foundation; version 2 of the License. Regards, Sergei

2 4

Re: [Maria-developers] MDEV-4904 - Add query cache hit information to Percona Response time distribution plugin (MDEV-4568)
by Sergei Golubchik 22 Jul '14

22 Jul '14

Hi, svoj! On Jun 26, svoj(a)mariadb.org wrote: > revision-id: f37f19a6c790100cc2ae5f483ba4db34a517f0ae > parent(s): 4a3f0684195703996b23c51af79cf946b85b8053 > committer: Sergey Vojtovich > branch nick: 10.1 > timestamp: 2014-06-26 16:37:46 +0400 > message: > > MDEV-4904 - Add query cache hit information to Percona Response time distribution plugin (MDEV-4568) > > Added two new fields to INFORMATION_SCHEMA.QUERY_RESPONSE_TIME: > QC_HITS_COUNT - query cache hits count > QC_HITS_TOTAL - cumulative response time for query cache hits. This is somewhat questionable feature. Queries served from qc don't take much time, which means that @@query_response_time_range_base should be different for them. Otherwise all qc hits will be in the first few slots. But a different base means a different table (QUERY_CACHE_RESPONSE_TIME ?) and a different set of configuration variables. On the other hand, this current implementation is much simpler. So I think we can accept this patch. But I don't know how useful it'll be. Alternatively, you can do a separate I_S table for QC. As you like. > diff --git a/plugin/query_response_time/mysql-test/query_response_time/query_response_time-stored.result b/plugin/query_response_time/mysql-test/query_response_time/query_response_time-stored.result > index bec7007..e487fc5 100644 > --- a/plugin/query_response_time/mysql-test/query_response_time/query_response_time-stored.result > +++ b/plugin/query_response_time/mysql-test/query_response_time/query_response_time-stored.result > @@ -40,51 +40,51 @@ SHOW GLOBAL VARIABLES where Variable_name like 'QUERY_RESPONSE_TIME_RANGE_BASE'; > Variable_name Value > query_response_time_range_base 2 > SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME; I'd rather replaced * with TIME,COUNT,TOTAL - less changes and more future proof. > -TIME COUNT TOTAL > - 0.000001 45 0.000000 > +TIME COUNT TOTAL QC_HITS_COUNT QC_HITS_TOTAL > + 0.000001 45 0.000000 0 0.000000 ... Regards, Sergei

1 0

[Maria-developers] Why does name resolution stop in crash stack trace?
by Sergey Petrunia 21 Jul '14

21 Jul '14

Hi, Look at today's crash report in maria-discuss@. A question not related to the cause of that crash: why do stack traces that go inside the storage engine cannot be resolved? Is something wrong with our build process? On Fri, Jun 13, 2014 at 08:15:39PM -0700, grantksupport(a)operamail.com wrote: > ==> /var/log/mariadb/mariadb-err.log <== > 140613 20:07:24 [ERROR] mysqld got signal 11 ; ... > Server version: 10.0.11-MariaDB-log > key_buffer_size=268435456 > read_buffer_size=1048576 > max_used_connections=1 > max_threads=66 > thread_count=1 > It is possible that mysqld could use up to > key_buffer_size + (read_buffer_size + > sort_buffer_size)*max_threads = 601410 K bytes of > memory > Hope that's ok; if not, decrease some variables in the > equation. > > Thread pointer: 0x0x7fcf132fa008 > Attempting backtrace. You can use the following > information to find out > where mysqld died. If you see no messages after this, > something went > terribly wrong... > stack_bottom = 0x7fcf4a6e4e78 thread_stack 0x100000 > /usr/local/mariadb/bin/mysqld(my_print_stacktrace+0x2e)[0xacb60e] > /usr/local/mariadb/bin/mysqld(handle_fatal_signal+0x390)[0x6f5a10] > /lib64/libpthread.so.0(+0xf9f0)[0x7fcf4ff2a9f0] > /usr/local/mariadb/bin/mysqld[0x915cba] > /usr/local/mariadb/bin/mysqld[0x909e27] > /usr/local/mariadb/bin/mysqld[0x90a35b] > /usr/local/mariadb/bin/mysqld[0x90c759] > /usr/local/mariadb/bin/mysqld[0x9169d5] > /usr/local/mariadb/bin/mysqld[0x8aaf2b] > /usr/local/mariadb/bin/mysqld[0x8ab3cf] > /usr/local/mariadb/bin/mysqld[0x8ab95a] > /usr/local/mariadb/bin/mysqld[0x895e80] > /usr/local/mariadb/bin/mysqld[0x89643f] > /usr/local/mariadb/bin/mysqld[0x9657da] > /usr/local/mariadb/bin/mysqld[0x965a16] > /usr/local/mariadb/bin/mysqld[0x96a51d] > /usr/local/mariadb/bin/mysqld[0x96ac28] > /usr/local/mariadb/bin/mysqld[0x82de54] > /usr/local/mariadb/bin/mysqld(_ZN7handler9ha_createEPKcP5TABLEP14HA_CREATE_INFO+0x70)[0x6fcbf0] > /usr/local/mariadb/bin/mysqld(_Z15ha_create_tableP3THDPKcS2_S2_P14HA_CREATE_INFOP34st_mysql_const_unsigned_lex_string+0x220)[0x6fd560] > /usr/local/mariadb/bin/mysqld(_Z16rea_create_tableP3THDP34st_mysql_const_unsigned_lex_stringPKcS4_S4_P14HA_CREATE_INFOP7handlerb+0xbb)[0x659d1b] > /usr/local/mariadb/bin/mysqld[0x62e50d] > /usr/local/mariadb/bin/mysqld(_Z26mysql_create_table_no_lockP3THDPKcS2_P14HA_CREATE_INFOP10Alter_infoPbi+0xd3)[0x62ee13] > /usr/local/mariadb/bin/mysqld(_Z18mysql_create_tableP3THDP10TABLE_LISTP14HA_CREATE_INFOP10Alter_info+0xb6)[0x62ef76] > /usr/local/mariadb/bin/mysqld(_Z21mysql_execute_commandP3THD+0x672d)[0x5be04d] > /usr/local/mariadb/bin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x1d7)[0x5bf4f7] > /usr/local/mariadb/bin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x15d7)[0x5c1057] > /usr/local/mariadb/bin/mysqld(_Z24do_handle_one_connectionP3THD+0x20c)[0x66f0ec] > /usr/local/mariadb/bin/mysqld(handle_one_connection+0x38)[0x66f138] > /usr/local/mariadb/bin/mysqld[0x9d5184] > /lib64/libpthread.so.0(+0x80db)[0x7fcf4ff230db] > /lib64/libc.so.6(clone+0x6d)[0x7fcf4ebd390d] > > Trying to get some variables. > Some pointers may be invalid and cause the dump to > abort. > Query (0x7fcf1143d020): CREATE TABLE menu_router ( BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] [GSoC] Week Nine!
by sriram patil 21 Jul '14

21 Jul '14

Hi All, There will be a little delay in the ninth week blog post. I need to get the code reviewed first to make the final changes. You can check the commit here <https://github.com/srirampatil/server/commit/3611bfc644714b797acff8b9884e7d…> though. I have also fixed MDEV-6409 <https://mariadb.atlassian.net/browse/MDEV-6409> and it is under review too. Regards, Sriram

1 0

[Maria-developers] Java Connector Coding till 20th July
by Puneet Dewan 20 Jul '14

20 Jul '14

Hi Everyone, Sorry,I did not update in the last week. It is because of my convocation and was meeting my parents after one year in Singapore, so enjoyed a small vacation of 5 days with them. I had code review and discussion with Massimo in that week. But I thought it is better to update next week. Things done: 1.I had initially written code in MySQLPreparedStatement.java but the code was getting ugly so as per recommnedation from Vladislav,I also discussed with my mentor.So we thought of using MySQLServerSidePreparedStatement as this will make code more cleaner. Now prepareStatement method in MySQLConnection will become the factory method to provide either MySQLPreparedStatement or MySQLServerSidePreparedStatement instance. I have migrated my code to MySQLServerSidePreparedStatement. 2.Test case for determining the type of instance, MySQLPreparedStatement or MySQLServerSidePreparedStatement. Next plan: 1.Write executeQuery and executeUpdate methods 2.For executeQuery, need to decide how I can use BinaryProtocolResultset to fetch results from a select query. 3.Write methods for batchstatements and multiqueries. Regards Puneet.

1 0

[Maria-developers] [GSoC] Optimize mysql-test-runs - Results of new strategy
by Pablo Estrada 17 Jul '14

17 Jul '14

Hello everyone, I took the last couple of days working on a new strategy to calculate the relevance of a test. The results are not sufficient by themselves, but I believe they point to an interesting direction. This strategy uses that rate of co-occurrence of events to estimate the relevance of a test, and the events that it uses are the following: - File editions since last run - Test failure in last run The strategy has also two stages: 1. Training stage 2. Executing stage In the training stage, it goes through the available data, and does the following: - If test A failed: - It counts and stores all the files that were edited since the last test_run (the last test_run depends on BRANCH, PLATFORM, and other factors) - If test A failed also in the previous test run, it also counts that In the executing stage, the training algorithm is still applied, but the decision of whether a test runs is based on its relevance, the relevance is calculated as the sum of the following: - The percentage of times a test has failed in two subsequent test_runs, multiplied by whether the test failed in the previous run (if the test didn't fail in the previous run, this quantity is 0) - For each file that was edited since the last test_run, the percentage of times that the test has failed after this file was edited (The explanation is a bit clumsy, I can clear it up if you wish so) The results have not been too bad, nor too good. With a running set of 200 tests, a training phase of 3000 test runs, and an executing stage of 2000 test runs, I have achieved recall of 0.50. It's not too great, nor too bad. Nonetheless, while running tests, I found something interesting: - I removed the first factor of the relevance. I decided to not care about whether a test failed in the previous test run. I was only using the file-change factor. Naturally, the recall decreased, from 0.50 to 0.39 (the decrease was not too big)... and the distribution of failed tests in the priority queue had a good skew towards the front of the queue (so it seems that the files help somewhat, to indicate the likelihood of a failure). I attached this chart. An interesting problem that I encountered was that about 50% of the test_runs don't have any file changes nor test failures, and so the relevance of all tests is zero. Here is where the original strategy (a weighted average of failures) could be useful, so that even if we don't have any information to guess which tests to run, we just go ahead and run the ones that have failed the most, recently. I will work on mixing up both strategies a bit in the next few days, and see what comes of that. By the way, I pushed the code to github. The code is completely different, so may be better to wait until I have new results soon. Regards! Pablo

2 11