July 2014 - developers - lists.mariadb.org

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

28 Jul '14

Hi Everyone, Last week, 1.Migrated the code from MySQLPreparedStatement to MySQLServerSidePreparedStatement. 2.Removed duplicate code in classes like IntParameter, DoubleParameter, LongParameter and used methods of class ParameterWriter(provides utility methods) in the above classes. 3.Did the analysis of TextProtocol Resultset has been implemented in connector code and find a way on how to write for Binary Protocol Resultset. 4.Fixed the new_params_bound_flag issue. 5.Code review with Massimo. This week, 1.Code review with Massimo 2.Complete the coding for Binary Protocol Resultset. 3.Write code for allowMultiQueries, Batchstatements. Regards Puneet.

1 0

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

27 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 20 Jul '14

20 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