- developers - lists.mariadb.org

Re: [Maria-developers] Active Directory authentication plugin - GSoC 2014
by Sergei Golubchik 05 Mar '14

05 Mar '14

Hi, Talina! On Feb 28, talinashrotriya(a)gmail.com wrote: > Hello Sir, > > My name is Talina, presently studying Computer Science from India. > > I am interested to work on the “Active Directory authentication plugin”project. I am good at C/C++ , MYSQL and also have good knowledge about Active directory. Could you suggest me a few links to get started with? > Eager to start work. > > Thanks! We don't have this project on the https://mariadb.com/kb/en/google-summer-of-code-2014/ anymore. I will add it back when we have a mentor for it. Regards, Sergei

1 0

[Maria-developers] MariaDB & MySQL community event 3rd of April 2014 in Santa Clara
by Michael Widenius 05 Mar '14

05 Mar '14

Hi! I am happy to announce that the MariaDB Foundation is organising a MariaDB & MySQL community event in Santa Clara on Thursday the 3rd of April. The venue is the Hilton Santa Clara hotel, a short walk from the Percona Live 2014 event. You can find more information on my blog at: http://monty-says.blogspot.fi/2014/03/mariadb-mysql-community-event-2014-in… We already got some very interesting talks and speakers, but I would like to see even more talk proposals. It's ok to propose a talk that it's also hold at Percona Live. As this event is free, I expect a totally different group of attendees, so that should be fine! When we have got a nice list of proposed talks, we will post them here so that everyone has a chance of commenting of which talks should be accepted. (Sorry, but this time we don't have time to create a proper selection committee so we have to do this a bit rough) Personally I will talk about MariaDB 10.0, which should be declared stable by then. Hope to see many MariaDB developers and users in Santa Clara! You can sign up for the event and/or dinner at: http://www.eventbrite.com/e/mariadb-mysql-community-event-2014-tickets-1080… Regards, Monty PS: Feel free to discuss the event on this email list! We want to have as many as possible participating in making this the best possible MariaDB and MySQL event.

1 0

[Maria-developers] regarding the project in gsoc 2014
by nitin goel 05 Mar '14

05 Mar '14

Sir/Ma'am, I would like to bring to your notice that i used 'mysql' to drop and create tables to understand project better but would like to know more specifications for the project 'create or replace, create if not exists, and drop if exists'. I have been working in C/C++ since 2010 and would like to learn more from you. Please also mention how to contact the mentor for the project and proceed further on project. Thanks Nitin Goel

2 1

[Maria-developers] MariaDB slave_parallel_threads and MySQL slave_parallel_workers
by Rasmus Johansson 05 Mar '14

05 Mar '14

Hi, I received a question that I wanted to share here to get some insight on. MariaDB 10.0 has a global setting named "slave_parallel_threads" and MySQL 5.7 has the same parameter named "slave_parallel_workers". Should slave_parallel_workers be an alias to slave_parallel_threads in MariaDB 10.0 to be more compatible with MySQL? BR, Rasmus -- Rasmus Johansson, VP Engineering MariaDB | t: +358 50 499 9589 | Skype: ratzpo

2 1

[Maria-developers] [GSoC] memcached priorities
by Tan Tran 04 Mar '14

04 Mar '14

Hi all, I'm looking to do my GSoC project with MariaDB, specifically the suggestion to "Port the InnoDB memcached interface to MariaDB" on the page https://mariadb.com/kb/en/google-summer-of-code-2014/ . But the project description links to a JIRA bug at https://mariadb.atlassian.net/browse/MDEV-4674 , where the author suggests that we support memcached through TCP/UDP instead, with no mention of the InnoDB plugin. I figure that the InnoDB plugin is more important, since it's a MySQL 5.6 feature, it's widespread in industry, and the lack of a memcache interface is one of only a handful X's for MariaDB on http://www.skysql.com/blogs/max-mether/mysql-56-vs-mariadb-100 . Additionally, even without TCP/UDP support, one could just code the memcache logic manually anyway, whereas the InnoDB integration is more sophisticated and feature-rich and would be a good selling point for SkySQL. So I'd like to start working on a proposal. Can any devs weigh in on which aspect of memcache is more desirable for MariaDB? If it sounds likes a good, straightforward GSoC project that nobody else has claimed yet? Thanks, Tan Tran

1 0

Re: [Maria-developers] Rev 4006: MDEV-5674 - Performance: my_hash_sort_bin is called too often
by Sergei Golubchik 04 Mar '14

04 Mar '14

Hi, Sergey! On Feb 14, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 4006 > revision-id: svoj(a)mariadb.org-20140214122541-tenvcllk760deai8 > parent: svoj(a)mariadb.org-20140213071355-psk0jpsarx2u7myc > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Fri 2014-02-14 16:25:41 +0400 > message: > MDEV-5674 - Performance: my_hash_sort_bin is called too often > > - reduced number of my_hash_sort_bin() calls from 4 to 2 per query. > Let MDL subsystem use pre-calculated hash value for hash > inserts and deletes. Is this necessary? One of the reasons why I didn't review this your first patch, because I believed that the second one obsoletes it. Why do you need my_hash_insert_using_hash_value() when you achieve the same effect with your calc_hash callback in the second patch? > - reduced number of memory accesses done by my_hash_sort_bin() I'd expect the compiler to handle it automatically, but feel free to change it, if it doesn't. Regards, Sergei

2 1

Re: [Maria-developers] MDEV-5674 - Performance: my_hash_sort_bin is called too often
by Sergei Golubchik 04 Mar '14

04 Mar '14

Hi, Sergey! On Feb 20, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 4007 > revision-id: svoj(a)mariadb.org-20140220072533-ko14y1714ouvd2f7 > parent: svoj(a)mariadb.org-20140214122541-tenvcllk760deai8 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Thu 2014-02-20 11:25:33 +0400 > message: > MDEV-5674 - Performance: my_hash_sort_bin is called too often It's MDEV-5675, not MDEV-5674 > Reuse MDL hash value in table cache: > - MDL namespace is excluded from hash value calculation, so that > hash value can be used by table cache as is > - hash value for MDL is calculated as resulting hash value + MDL > namespace > - extended hash implementation to accept user defined hash function This looks ok. I have a couple of comments, but they are mostly a question of taste. Up to you, you can push as is too. > === modified file 'sql/mdl.cc' > --- a/sql/mdl.cc 2014-02-14 12:25:41 +0000 > +++ b/sql/mdl.cc 2014-02-20 07:25:33 +0000 > @@ -760,13 +760,22 @@ void MDL_map::init() > } > > > +my_hash_value_type mdl_hash_function(const CHARSET_INFO *cs, > + const uchar *key, size_t length) > +{ > + return *((my_hash_value_type*) (key - offsetof(MDL_key, m_ptr) + > + offsetof(MDL_key, m_hash_value))) + > + key[0]; I'd prefer to avoid pointer and offset juggling. Because you use a custom hash function anyway, you can directly pass MDL_key as your "key", then here you can use ((MDL_key*)key)->hash_value() > +} > + > /** Initialize the partition in the container with all MDL locks. */ > > === modified file 'sql/mdl.h' > --- a/sql/mdl.h 2014-02-14 12:25:41 +0000 > +++ b/sql/mdl.h 2014-02-20 07:25:33 +0000 > @@ -397,7 +396,11 @@ class MDL_key > { > return & m_namespace_to_wait_state_name[(int)mdl_namespace()]; > } > - ulong hash_value() const > + my_hash_value_type hash_value() const > + { > + return m_hash_value + m_ptr[0]; I'm not sure it's a good idea, + is not a very good hash function :) On the other hand, I don't see anything immediately wrong with it in this particular case. Ok, let it be. Anyway, could you please use mdl_namespace() instead of m_ptr[0] where possible? > @@ -405,12 +408,14 @@ class MDL_key > private: > MDL_key(const MDL_key &); /* not implemented */ > MDL_key &operator=(const MDL_key &); /* not implemented */ > + friend my_hash_value_type mdl_hash_function(const CHARSET_INFO *, > + const uchar *, size_t); You probably wouldn't need this friend, if you'd change mdl_hash_function() to use MDL_key::hash_value() Regards, Sergei

2 5

[Maria-developers] Suggestion ,a new member
by anupama vijjapu 04 Mar '14

04 Mar '14

Hello fellow developers, I joined MariaDB community today and need few suggestions/projects/bugs that i can work on. I do not have any knowledge of MariaDB source, but I will start looking into it now. I have hands on experience in C/C++/Java/Python and MySQL Database. Any suggestions/recommendation are highly appreciated.

2 1

Re: [Maria-developers] Rev 4029: MDEV-4856 SQL_ERROR_LOG shows 1146 errors which didnt appear in mysql client
by Sergei Golubchik 03 Mar '14

03 Mar '14

Hi, Holyfoot! On Jan 31, holyfoot(a)askmonty.org wrote: > revno: 4029 > revision-id: holyfoot(a)askmonty.org-20140131103303-1rx7ielo83f8iahe > parent: holyfoot(a)askmonty.org-20140124020722-dd5twtwlcc8o1xiy > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-4856 > timestamp: Fri 2014-01-31 14:33:03 +0400 > message: > MDEV-4856 SQL_ERROR_LOG shows 1146 errors which didnt appear in mysql client. > The fill_schema_table() function used to call get_table_share() for > a table name in WHERE then clear the error list. That way plugins > receive the superfluous error notification if it happens in it. Also > the problem was that error handler didn't prevent the suppressed > error message from logging anyway as the logging happens in > THD::raise_condition before the handler call. > Fixed by adding the No_table_error_handler before the call. > raise_condition() also fixed. > === modified file 'sql/sql_class.cc' > --- a/sql/sql_class.cc 2014-01-23 18:21:02 +0000 > +++ b/sql/sql_class.cc 2014-01-31 10:33:03 +0000 > @@ -1145,7 +1145,6 @@ MYSQL_ERROR* THD::raise_condition(uint s > got_warning= 1; > break; > case MYSQL_ERROR::WARN_LEVEL_ERROR: > - mysql_audit_general(this, MYSQL_AUDIT_GENERAL_ERROR, sql_errno, msg); > break; > default: > DBUG_ASSERT(FALSE); > @@ -1156,6 +1155,8 @@ MYSQL_ERROR* THD::raise_condition(uint s > > if (level == MYSQL_ERROR::WARN_LEVEL_ERROR) > { > + mysql_audit_general(this, MYSQL_AUDIT_GENERAL_ERROR, sql_errno, msg); > + This is good. > === modified file 'sql/sql_show.cc' > --- a/sql/sql_show.cc 2013-11-19 12:16:25 +0000 > +++ b/sql/sql_show.cc 2014-01-31 10:33:03 +0000 > @@ -4199,8 +4199,13 @@ static int fill_schema_table_from_frm(TH > key_length= create_table_def_key(thd, key, &table_list, 0); > hash_value= my_calc_hash(&table_def_cache, (uchar*) key, key_length); > mysql_mutex_lock(&LOCK_open); > - share= get_table_share(thd, &table_list, key, > - key_length, OPEN_VIEW, &not_used, hash_value); > + { > + No_such_table_error_handler no_such_table_handler; > + thd->push_internal_handler(&no_such_table_handler); > + share= get_table_share(thd, &table_list, key, > + key_length, OPEN_VIEW, &not_used, hash_value); > + thd->pop_internal_handler(); > + } But I don't understand that. Do you mean, old code did *not* suppress errors here? How could selects from I_S tables work without it? Regards, Sergei

2 5

[Maria-developers] New member, Need suggestion
by Neil Shah 03 Mar '14

03 Mar '14

Hello fellow developers, I joined MariaDB community today and need few suggestions/projects/bugs that i can work on. I do not have any knowledge of MariaDB source, but I will start looking into it now. I have hands on experience in C/C++/Java/Python and MySQL Database. Any suggestions/recommendation are highly appreciated. -- Thanks & Regards Neil Shah

2 3

[Maria-developers] slave_ddl_exec_mode and incompatible change in MariaDB 10.0.8
by Pavel Ivanov 03 Mar '14

03 Mar '14

Hi, I've discovered a change in MariaDB 10.0.8 that I don't quite understand motivation for and which looks really surprising to me. So I would appreciate if you could tell me what's the motivation and why you think it's appropriate to do that. The change in question is http://bazaar.launchpad.net/~maria-captains/maria/10.0/revision/3961.1.7. I see several issues with it: 1. It introduces a pretty significant variable slave_ddl_exec_mode which wasn't announced in the Release Notes. 2. The default variable value was set to IDEMPOTENT which changes MariaDB slave behavior in an incompatible way. Not everyone will want to have this variable set to IDEMPOTENT (I'd actually argue that no one should set it to IDEMPOTENT), but without any mentioning of this variable in the Release Notes people basically have the only chance to get knowledge about this change (let me stress out: _incompatible_ change) from production incidents or from accidental code inspection. 3. When slave_ddl_exec_mode is set to IDEMPOTENT every "DROP TABLE" event in master's binlog is converted into "DROP TABLE IF EXISTS" in slave's binlog, which I believe is a major no-no for replication. Binlogs on master and slave should be identical, otherwise after failover even if one would set slave_ddl_exec_mode = STRICT it will still execute "DROP TABLE IF EXISTS" because new master has that in binlogs. 4. Why this change introduces OPTION_GTID_BEGIN in the code? Why OPTION_BEGIN wasn't enough? From reading the code the only thing I understand is that with broken binlogs and sequence of events "GTID BEGIN; CREATE TABLE; CREATE TABLE" MariaDB will try to execute both CREATE TABLE statements in the same transaction without auto-committing at the end. This sounds pretty crazy to me. And given the fact that in normal situation such sequence of events on the master is not possible it seems that existence of both OPTION_BEGIN and OPTION_GTID_BEGIN only introduces confusion (MariaDB have GTID always on, right? So it should always execute GTID_BEGIN and never BEGIN without GTID, right?). So what is your word on this? Can you at least set default value for slave_ddl_exec_mode to STRICT so that slave behavior didn't change with the version upgrade? Thank you, Pavel

2 7

Re: [Maria-developers] MariaDB Master Replication To MySQL
by Kristian Nielsen 03 Mar '14

03 Mar '14

> In this particular case, we have someone that wants to use MariaDB 10.0 master with a MySQL 5.6 slave. But they are running into a problem with GTID. Generally, the recommended setup is to only replicate from old version on master to new (or same) version on slave. Replicating from new master to old slave in general is hard to support 100%, as there may be eg. new SQL syntax on the master that is impossible for the old version slave to execute. That being said, the intention is that replication from new master to old slave (like MariaDB 10.0 -> MySQL 5.6) should work in most reasonable cases. So this sounds like a bug which might be worth filing. > 2.) Is it possible to disable GTID in 10.0? It seems like it would break a few other things like parallel replication, but they're only running MariaDB on the master. GTID is disabled automatically when the slave does not support it. The code rewrites the binlog stream on the fly to remove events that are not supported on the old slave, and replace them with something appropriate for that slave version. Does the same problem occur when replicating from MariaDB 10.0 master to MariaDB 5.5 slave? What about when replicating from MySQL 5.5 master to MySQL 5.6 slave? - Kristian.

1 0

Re: [Maria-developers] MDEV-5755 - Scalability: let LOCK_open and THR_LOCK::mutex be normal mutexes
by Sergei Golubchik 03 Mar '14

03 Mar '14

Hi, Sergey! On Feb 27, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 4011 > revision-id: svoj(a)mariadb.org-20140227141521-fgj5b0h3qbijyojh > parent: svoj(a)mariadb.org-20140220072533-l3au3y7mrsyclfpb > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Thu 2014-02-27 18:15:21 +0400 > message: > MDEV-5755 - Scalability: let LOCK_open and THR_LOCK::mutex be normal mutexes > > Normal mutexes scale better than adaptive at high thread count. > At low thread count they behave similarly. To summarize Axel results: at low concurency normal can be ~1% slower. at high concurrency r/o - normal are up to 25% faster. at high concurrency r/w - normal are up to 10% slower. That last result bothers me a litte. Regards, Sergei

2 1

[Maria-developers] MDEV-5081 - Simple performance improvement for MariaDB
by Sergey Vojtovich 28 Feb '14

28 Feb '14

Hi Sergei, do you know if we ship any binaries with fast mutex (-DMY_PTHREAD_FASTMUTEX) enabled or officially suggest it? What was it's intention and what loads it was supposed to make faster? I'm trying to understand if fastmutex is worth fixing. It looks like duplication of PTHREAD_MUTEX_ADAPTIVE_NP, so we have double spinning when they're enabled. According to my recent benchmarks it shown worst performance. Thanks, Sergey

3 5

[Maria-developers] Keystone authentication plugin GSoc 14
by Abhishek Solanki 28 Feb '14

28 Feb '14

Hello MariaDB members , I am interested to work on "Keystone authentication plugin" project , i have a good knowledge of C/C++ and OpenStack. So can anyone help me how to get started with this project, so that i cold dig something before applying for this project. -- Thanks, Abhishek

2 1

[Maria-developers] Debian build / multi-architecture related bugs filed
by Otto Kekäläinen 27 Feb '14

27 Feb '14

Hello! The Debian build status can be seen at https://buildd.debian.org/status/package.php?p=mariadb-5.5 (and for MySQL at https://buildd.debian.org/status/package.php?p=mysql-5.5) The sparc build issue already got solved but for the others I filed the following bugs (as each failure seems to have different cause): https://mariadb.atlassian.net/browse/MDEV-5708 https://mariadb.atlassian.net/browse/MDEV-5707 https://mariadb.atlassian.net/browse/MDEV-5706 Could somebody please look into these? I assume that some of them might be easy if MySQL already has them solved, then all that needs to be done is to copy a patch from MySQL upstream or from MySQL patches in Debian (see http://anonscm.debian.org/gitweb/?p=pkg-mysql/mysql-5.5.git;a=tree;f=debian…) (MariaDB Debian builds are pulled from http://anonscm.debian.org/gitweb/?p=pkg-mysql/mariadb-5.5.git and mirrored at https://github.com/ottok/mariadb-5.5) Also, here are two QA issues that are related. I am not sure what to do with them: http://qa.debian.org/bls/packages/m/mariadb-5.5.html

1 1

[Maria-developers] Problem with debug_sync, THD::enter_cond(), and kill ...
by Kristian Nielsen 26 Feb '14

26 Feb '14

I got a crash in my parallel replication test case, and this one turned out to be caused by a fundamental problem in debug_sync. I am not sure how to solve it, so I wanted to explain the issue in case others have some ideas. The crash happens in THD::awake() when a thread is killed: mysql_mutex_lock(&mysys_var->mutex); ... int ret= mysql_mutex_trylock(mysys_var->current_mutex); mysql_cond_broadcast(mysys_var->current_cond); if (!ret) mysql_mutex_unlock(mysys_var->current_mutex); The problem is that mysys_var->current_mutex changed between the trylock() and the unlock(), so we unlock a different mutex than the one we locked - ouch! The mutex changed because of this code in debug_sync.cc: if (thd->mysys_var) { old_mutex= thd->mysys_var->current_mutex; old_cond= thd->mysys_var->current_cond; thd->mysys_var->current_mutex= &debug_sync_global.ds_mutex; thd->mysys_var->current_cond= &debug_sync_global.ds_cond; } There is no mutex protection here. So this means that it is not safe to use debug_sync inside enter_cond()/exit_cond() if kill will be used on the thread at that point. Since I have a lot of tests for parallel replication where I test exactly for correct error handling when killing threads at various points in the parallel processing, it is not too surprising that I would eventually be hit by this :) I am going to avoid using debug_sync inside enter_cond()/exit_cond() for now. But any ideas for how to solve this properly? This is particularly nasty to be hit by, as it is not at all obvious that this use of debug_sync should be a problem. And it is not exactly easy to guess from the failure what the real problem is - assuming one can even reproduce the failure, the window of opportunity in the race is after all rather quite small. - Kristian.

3 4

[Maria-developers] How handle_rpl_parallel_thread rollback partial transaction when STOP SLAVE In parallel replication
by nanyi607rao 26 Feb '14

26 Feb '14

hi Kristian, I have a quesion about parallel replication. In handle_rpl_parallel_thread(), a worker thread has got a whole transaction events, but it only apply partial events. this thread wouldl skip left events when do STOP SLAVE(is that rigth?) ,because sql_worker_killed() return true. but it seems that partial transaction won't be rollbacked for wait_for_prior_commit() always return false. do me wrong? or how would it rollback that partial transaction. 2014-02-25 nanyi607rao

2 3

[Maria-developers] GSOC 2014 participation
by Suyash Loiwal 26 Feb '14

26 Feb '14

Hello I am Suyash Loiwal from India, currently pursuing my B.Tech from Manipal institute of Technology, Manipal. I would like to take a project under your organization. Can someone please guide me how to start? Thanks Suyash

2 1

[Maria-developers] MDEV-4309: Review for 201402181003_sanja_copy_calls_patch.diff
by Sergey Petrunia 25 Feb '14

25 Feb '14

Hi Sanja, My input for 201402181003_sanja_copy_calls_patch.diff: * memcpy_field_possible() should have a function comment mentioning that it checks whether memcpy_field_value() can be used. * field_conv_incompatible() should have a function comment mentioning that it is a function that is used instead of field_conv() when we know in advance that memcpy_field_possible(...)==false. Ok to push after this is addressed. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MariaDB 5.5.36 stable and MariaDB Galera 10.0.7 alpha release prep
by Daniel Bartholomew 25 Feb '14

25 Feb '14

All, I've completed most of the prep work for the MariaDB 5.5.36 (stable) and MariaDB Galera Cluster 10.0.7 (alpha) releases. Current plan is to activate and announce these releases together on Monday, 24 Feb before noon US Eastern Time (barring any last-minute issues). Draft changelogs and release notes are at the following locations: MariaDB 5.5.36 stable - https://mariadb.com/kb/en/mariadb-5536-release-notes/ - https://mariadb.com/kb/en/mariadb-5536-changelog/ MariaDB Galera Cluster 10.0.7 alpha - https://mariadb.com/kb/en/mariadb-galera-cluster-1007-release-notes/ - https://mariadb.com/kb/en/mariadb-galera-cluster-1007-changelog/ Please let me know ASAP of any additions, changes, typos, etc.... The 5.5.36 release notes in particular are very generic at the moment, so I'm very interested in additions to that page (please jump in and add!). The files for these releases are gradually making their way to MariaDB mirrors world wide. The primary mirror has them now if you want to get a jump on the competition: http://ftp.osuosl.org/pub/mariadb/mariadb-galera-10.0.7 http://ftp.osuosl.org/pub/mariadb/mariadb-5.5.36 Obilgatory note #1: The plan is for these files to be the officially released files without any changes, but that may change if something unexpected comes up (and such things have happened in the past). For those that would like to test the MariaDB Galera Cluster 10.0.7-alpha yum and apt repositories prior to the actual release, because that's just how you roll, the following config entries should get you going (you'll need to copy/paste/edit for whatever distro you are actually using/testing/playing-around-with): # - - Ubuntu - - - - - - - - - - - - - - - - # MariaDB 10.0.8 Ubuntu test mariadb.list w/MGC 10.0.7-alpha deb http://ftp.osuosl.org/pub/mariadb/mariadb-10.0.8/repo/ubuntu saucy main # - - Debian - - - - - - - - - - - - - - - - - # MariaDB 10.0.8 Debian test mariadb.list w/MGC 10.0.7-alpha deb http://ftp.osuosl.org/pub/mariadb/mariadb-10.0.8/repo/debian wheezy main # - - Red Hat - - - - - - - - - - - - - - - - # MariaDB 10.0.8 RedHat MariaDB-test.repo w/ MGC 10.0.7-alpha [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.0.8-upd/rhel6-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 # - - Fedora - - - - - - - - - - - - - - - - - # MariaDB 10.0.8 Fedora MariaDB-test.repo w/ MGC 10.0.7-alpha [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.0.8-upd/fedora20-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1 Obligatory note #2: These test alpha repos, if you use them, should be switched to the official ones (as produced by the repository configuration generator) after the release is officially out. Obligatory disclaimer #1: These test alpha repos are _completely_ untested. They may not work at all. Obligatory disclaimer #2: MariaDB Galera Cluster 10.0.7 is an ALPHA release. You have been warned. You're on your own. Good luck and Godspeed. :) Thanks. -- Daniel Bartholomew MariaDB

4 4

[Maria-developers] MySQL Optimizer Trace Questions
by Christian Rober 25 Feb '14

25 Feb '14

Hello All, I work for TokuTek as a Storage Engine developer and I have been using the, relatively, new optimizer trace functionality. I have found the results very helpful when combined with analyzing the source code, but there a few questions I want to ask. Here is some output from the trace for a recent SELECT query on an InnoDB table: At the end of the trace, it shows the index chosen by, what I presume, is the optimizer: ... "considered_execution_plans": [ { "plan_prefix": [], "table": "`reports` `a`", "best_access_path": { "considered_access_paths": [ { "access_type": "ref", "index": "reports_group_id", "rows": 1.55e6, "cost": 411057, "chosen": true }, ... ] }, "cost_for_plan": 411057, "rows_for_plan": 1.55e6, "chosen": true } ] }, ... Here are the cost results for some rejected alternative indexes, (note: the row count for two of them is similar to the chosen index): ... "analyzing_range_alternatives": { "range_scan_alternatives" ... "rows": 2377102, "cost": 2.81e6, ... "rows": 1554164, "cost": 1.84e6, ... "rows": 2346664, "cost": 2.78e6, ... "rows": 1554164, "cost": 1.84e6, ... Here is the cost analysis for a table scan, from the beginning of the trace (still not as good as the above chosen index, but close on cost): ... "table": "`reports` `a`", "range_analysis": { "table_scan": { "rows": 3108329, "cost": 655076 }, ... Related to the fact that the table scan analysis is dominated by the large row count, and probably rejected as a valid plan compared to the chosen index for that very reason: 1. How is the row count more than merely informational to the optimizer? I had the impression the row count did not directly contribute to the optimizer's decision as much as the estimated cost, or that the row count was already accounted for/factored into in the final cost measurement. 2. Related to that question, what is cost exactly? Is there a unit of measurement (ex: Time, Disk Seeks, etc.)? 3. Is cost more important than row count or equally important? 4. What is the genesis of the cost variable displayed in the trace? I assume it is just a guess on the respective storage engine's part of how expensive (in terms of disk access, processing, time, etc.) getting the rows will be for the query. thanks in advance, Christian

2 1

[Maria-developers] We are participating in Google Summer of Code 2014
by Colin Charles 25 Feb '14

25 Feb '14

Hi, It is with great pleasure that I can inform you that we have been accepted as an organisation to participate in Google Summer of Code 2014! It would be great to see more ideas pop up here: https://mariadb.com/kb/en/google-summer-of-code-2014/ More mentors are always wanted! I presume we will see a lot more student discussions here as well. If you have any questions that aren't answered on the lists, please send me a personal note Here's to more features & contributors in 2014. cheers, -colin -- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles

1 0

[Maria-developers] MariaDB C-API and specific P_S tables
by Peter Laursen 24 Feb '14

24 Feb '14

THis is probably a question that Gerog Richter (or possibly Wlad) could reply to. I came across this bug report: http://bugs.mysql.com/bug.php?id=71801 .. files by former MySQL/Sun/Oracle supporter Veleriuy Kravtchuk We have a 64 bit C-application compiled with MariaDB C-API (on and for Windows 64 bit). I connect to MySQL 5.6.15 and execute SELECT * FROM `session_connect_attrs`; /* PROCESSLIST_ID ATTR_NAME ATTR_VALUE ORDINAL_POSITION -------------- --------------- ---------- ------------------ 2 _os Windows 0 2 _client_name libmariadb 1 2 _pid 5012 2 2 _thread 4640 3 2 _platform x86 4 2 _client_version 1.1.2 5 */ With the MySQL CLI 5.6.15, you will get /* PROCESSLIST_ID ATTR_NAME ATTR_VALUE ORDINAL_POSITION -------------- --------------- ---------- ------------------ 4 _os Win64 0 4 _client_name libmysql 1 4 _pid 4888 2 4 _thread 4320 3 4 _platform x86_64 4 4 program_name mysql 5 4 _client_version 5.6.15 6 */ The differences I notice are * Our application populates P_S with "Windows" - not "Win64" as the 5.6.15 CLI * Our application populates 'P_S with "x86" and not "x86_64". * Our application does not populate P_S with a "program_name". But it has a name of course! MySQL 5.6 docs at http://dev.mysql.com/doc/refman/5.6/en/performance-schema-connection-attrib… (as far as I can understand) that the client should use mysql_options() and mysql_options4() C API functions to populate P_S with all information. I have two questions: 1) Will the first 2 differences listed require a patch in our code or in libmariadb? 2) Obviosuly the lacking program name in the P_S tables is something that we will neeed to take care of ourselves. However I think that mysql_options4() was added in MySQL 5.6 and the MariaDB API does not supprot it currently (it is targeted to be compatible with Oracle 5.5 API, I think). And to populate the program name we may need to use mysql_options4(). Am I right?

2 4

[Maria-developers] Using MariaDB SQL for other storage engine
by Amith Nagarajappa 24 Feb '14

24 Feb '14

Hello, I am a database guy and want to plug mariaDB sql engine for other storage engine. If I want to plugin a storage engine with mariadb to use mariadb's SQL should i use handler interface in the storage/examples directory. I am not sure how to start with this interface implementation for MariaDB. Any help or docs or weblink on this would be helpful. Thanks and Regards, Amith

3 4

[Maria-developers] GROUP BY with non-grouped column returns NULL in some cases?
by Pavel Ivanov 24 Feb '14

24 Feb '14

Hi, I've noticed a difference in MariaDB's behavior compared to its documentation and compared to MySQL 5.1 (didn't check with MySQL 5.5 or 5.6 yet), and I wanted to know what's your opinion -- is it a bug or a conscious difference and documentation is just lagging. This doc https://mariadb.com/kb/en/select/#group-by says: "If you select a non-grouped column or a value computed from a non-grouped column, it is undefined which row the returned value is taken from". I believe this implies that selected value must be returned from a row group, not just something random. But I have a scenario when NULL is returned instead of real values. I understand that this is completely undefined behavior in SQL standard, but MySQL and MariaDB seem to have a documented support for this, that's why I'm asking. Here's the mysql session log: Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 5 Server version: 10.0.8-MariaDB-log Source distribution Copyright (c) 2000, 2013, Oracle, Monty Program Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [(none)]> create database test; Query OK, 1 row affected (0.00 sec) MariaDB [(none)]> use test; Database changed MariaDB [test]> CREATE TABLE t (id bigint(20), name varchar(30), parent bigint(20), primary key (id)) ENGINE=InnoDB; Query OK, 0 rows affected (0.27 sec) MariaDB [test]> INSERT INTO t values (1, 'a', NULL), (4, 'b', 1), (5, 'c', 4), (10, 'd', 1); Query OK, 4 rows affected (0.04 sec) Records: 4 Duplicates: 0 Warnings: 0 MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id and t2.name <> 'a') GROUP BY t1.id; +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | NULL | NULL | | 5 | c | NULL | NULL | | 10 | d | NULL | NULL | +----+------+------+------+ 4 rows in set (0.00 sec) MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id and t2.name <> 'a'); +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | NULL | NULL | | 5 | c | 4 | b | | 10 | d | NULL | NULL | +----+------+------+------+ 4 rows in set (0.00 sec) MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id and t2.name <> 'a') GROUP BY t1.id, t1.name; +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | NULL | NULL | | 5 | c | 4 | b | | 10 | d | NULL | NULL | +----+------+------+------+ 4 rows in set (0.00 sec) MariaDB [test]> SELECT t1.id, t1.name, t2.id, t2.name FROM t t1 LEFT OUTER JOIN t t2 ON (t1.parent = t2.id) GROUP BY t1.id; +----+------+------+------+ | id | name | id | name | +----+------+------+------+ | 1 | a | NULL | NULL | | 4 | b | 1 | a | | 5 | c | 4 | b | | 10 | d | 1 | a | +----+------+------+------+ 4 rows in set (0.00 sec) As you see the first query returns NULLs instead of real values which can be seen in second query without GROUP BY. And if I add another column to GROUP BY or remove one condition from JOIN I can see real values again. I've also tested with the table without PRIMARY KEY and it also returned real values in the first query. So is this a bug? Thank you, Pavel

2 2

[Maria-developers] Interested in GSOC
by Gopichand Paturi 24 Feb '14

24 Feb '14

Dear Sir/Madam, I am a student of Computer Science at BITS PILANI, India. I am interested in working as a developer for MariaDB in 2014. Can someone please let me know the ideas and proposed projects this year? Someone please guide me what to familiarize myself to be helpful and contribute for MariaDB. I am C++ developer....with good knowledge in Data Structures,Algorithms,Database Systems. Thanks& Regards, Gopichand.

2 1

[Maria-developers] Proposal for: MDEV-5244: Make extended_keys=ON by default in 10.0
by Sergey Petrunia 22 Feb '14

22 Feb '14

Hello, I was looking at how to make extended_keys=ON by default in 10.0. There haven't been any bugs in the feature for quite some time, but we still have a question of how to be with the testsuite (do we run it with extended_keys=OFF, the old way, or with extended_keys=ON, the new way? both approaches have their advantages) So, I've just changed the default, and ran the default set of test suites. A total 12 tests fail, of those only 3 tests fail in the way that indicates that extended keys feature had an impact on the testcase (e.g. it got a different execution plan and probably no longer tests what it used to test). For these, I intend to place set opimizer_switch='extended_keys=off' <testcase> set opimizer_switch='extended_keys=on' around the affected testcases. The cases are: range_vs_index_merge_innodb - switch @@optimizer_switch (~3 testcases) index_merge_innodb - switch @@optimizer_switch (1 testcase) innodb.innodb_mysql -switch @@optimizer_switch (1 testcase) Any comments/input on this? BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] [svoj@mariadb.org: [Commits] Rev 4006: MDEV-5674 - Performance: my_hash_sort_bin is called too often in lp:maria/10.0]
by Sergey Vojtovich 20 Feb '14

20 Feb '14

Hi! JFYI: we discussed this during the Barcelona meeting. I will submit table cache part separately (not to overcomplicate this patch). Reviewers are very welcome. Regards, Sergey ----- Forwarded message from Sergey Vojtovich <svoj(a)mariadb.org> ----- Date: Fri, 14 Feb 2014 12:25:50 +0000 (UTC) From: Sergey Vojtovich <svoj(a)mariadb.org> To: commits(a)mariadb.org Subject: [Commits] Rev 4006: MDEV-5674 - Performance: my_hash_sort_bin is called too often in lp:maria/10.0 At lp:maria/10.0 ------------------------------------------------------------ revno: 4006 revision-id: svoj(a)mariadb.org-20140214122541-tenvcllk760deai8 parent: svoj(a)mariadb.org-20140213071355-psk0jpsarx2u7myc committer: Sergey Vojtovich <svoj(a)mariadb.org> branch nick: 10.0 timestamp: Fri 2014-02-14 16:25:41 +0400 message: MDEV-5674 - Performance: my_hash_sort_bin is called too often - reduced number of my_hash_sort_bin() calls from 4 to 2 per query. Let MDL subsystem use pre-calculated hash value for hash inserts and deletes. - reduced number of memory accesses done by my_hash_sort_bin() === modified file 'include/hash.h' --- a/include/hash.h 2013-09-14 01:09:36 +0000 +++ b/include/hash.h 2014-02-14 12:25:41 +0000 @@ -86,7 +86,13 @@ uchar *my_hash_first_from_hash_value(con uchar *my_hash_next(const HASH *info, const uchar *key, size_t length, HASH_SEARCH_STATE *state); my_bool my_hash_insert(HASH *info, const uchar *data); +my_bool my_hash_insert_using_hash_value(HASH *info, + my_hash_value_type hash_value, + const uchar *record); my_bool my_hash_delete(HASH *hash, uchar *record); +my_bool my_hash_delete_using_hash_value(HASH *hash, + my_hash_value_type hash_value, + uchar *record); my_bool my_hash_update(HASH *hash, uchar *record, uchar *old_key, size_t old_key_length); void my_hash_replace(HASH *hash, HASH_SEARCH_STATE *state, uchar *new_row); === modified file 'mysys/hash.c' --- a/mysys/hash.c 2013-09-14 01:09:36 +0000 +++ b/mysys/hash.c 2014-02-14 12:25:41 +0000 @@ -380,6 +380,15 @@ static int hashcmp(const HASH *hash, HAS my_bool my_hash_insert(HASH *info, const uchar *record) { + return my_hash_insert_using_hash_value(info, rec_hashnr(info, record), + record); +} + + +my_bool my_hash_insert_using_hash_value(HASH *info, + my_hash_value_type hash_value, + const uchar *record) +{ int flag; size_t idx,halfbuff,first_index; my_hash_value_type hash_nr; @@ -480,7 +489,7 @@ my_bool my_hash_insert(HASH *info, const } /* Check if we are at the empty position */ - idx= my_hash_mask(rec_hashnr(info, record), info->blength, info->records + 1); + idx= my_hash_mask(hash_value, info->blength, info->records + 1); pos=data+idx; if (pos == empty) { @@ -528,6 +537,15 @@ my_bool my_hash_insert(HASH *info, const my_bool my_hash_delete(HASH *hash, uchar *record) { + return my_hash_delete_using_hash_value(hash, rec_hashnr(hash, record), + record); +} + + +my_bool my_hash_delete_using_hash_value(HASH *hash, + my_hash_value_type hash_value, + uchar *record) +{ uint pos2,idx,empty_index; my_hash_value_type pos_hashnr, lastpos_hashnr; size_t blength; @@ -539,7 +557,7 @@ my_bool my_hash_delete(HASH *hash, uchar blength=hash->blength; data=dynamic_element(&hash->array,0,HASH_LINK*); /* Search after record with key */ - pos= data + my_hash_mask(rec_hashnr(hash, record), blength, hash->records); + pos= data + my_hash_mask(hash_value, blength, hash->records); gpos = 0; while (pos->data != record) === modified file 'sql/mdl.cc' --- a/sql/mdl.cc 2013-12-10 15:31:04 +0000 +++ b/sql/mdl.cc 2014-02-14 12:25:41 +0000 @@ -124,15 +124,9 @@ class MDL_map_partition public: MDL_map_partition(); ~MDL_map_partition(); - inline MDL_lock *find_or_insert(const MDL_key *mdl_key, - my_hash_value_type hash_value); - unsigned long get_lock_owner(const MDL_key *key, - my_hash_value_type hash_value); + inline MDL_lock *find_or_insert(const MDL_key *mdl_key); + unsigned long get_lock_owner(const MDL_key *key); inline void remove(MDL_lock *lock); - my_hash_value_type get_key_hash(const MDL_key *mdl_key) const - { - return my_calc_hash(&m_locks, mdl_key->ptr(), mdl_key->length()); - } private: bool move_from_hash_to_lock_mutex(MDL_lock *lock); /** A partition of all acquired locks in the server. */ @@ -846,11 +840,10 @@ MDL_lock* MDL_map::find_or_insert(const return lock; } - my_hash_value_type hash_value= m_partitions.at(0)->get_key_hash(mdl_key); - uint part_id= hash_value % mdl_locks_hash_partitions; + uint part_id= mdl_key->hash_value() % mdl_locks_hash_partitions; MDL_map_partition *part= m_partitions.at(part_id); - return part->find_or_insert(mdl_key, hash_value); + return part->find_or_insert(mdl_key); } @@ -863,15 +856,14 @@ MDL_lock* MDL_map::find_or_insert(const @retval NULL - Failure (OOM). */ -MDL_lock* MDL_map_partition::find_or_insert(const MDL_key *mdl_key, - my_hash_value_type hash_value) +MDL_lock* MDL_map_partition::find_or_insert(const MDL_key *mdl_key) { MDL_lock *lock; retry: mysql_mutex_lock(&m_mutex); if (!(lock= (MDL_lock*) my_hash_search_using_hash_value(&m_locks, - hash_value, + mdl_key->hash_value(), mdl_key->ptr(), mdl_key->length()))) { @@ -902,7 +894,9 @@ MDL_lock* MDL_map_partition::find_or_ins lock= MDL_lock::create(mdl_key, this); } - if (!lock || my_hash_insert(&m_locks, (uchar*)lock)) + if (!lock || my_hash_insert_using_hash_value(&m_locks, + mdl_key->hash_value(), + (uchar*) lock)) { if (unused_lock) { @@ -1023,10 +1017,9 @@ MDL_map::get_lock_owner(const MDL_key *m } else { - my_hash_value_type hash_value= m_partitions.at(0)->get_key_hash(mdl_key); - uint part_id= hash_value % mdl_locks_hash_partitions; + uint part_id= mdl_key->hash_value() % mdl_locks_hash_partitions; MDL_map_partition *part= m_partitions.at(part_id); - res= part->get_lock_owner(mdl_key, hash_value); + res= part->get_lock_owner(mdl_key); } return res; } @@ -1034,15 +1027,14 @@ MDL_map::get_lock_owner(const MDL_key *m unsigned long -MDL_map_partition::get_lock_owner(const MDL_key *mdl_key, - my_hash_value_type hash_value) +MDL_map_partition::get_lock_owner(const MDL_key *mdl_key) { MDL_lock *lock; unsigned long res= 0; mysql_mutex_lock(&m_mutex); lock= (MDL_lock*) my_hash_search_using_hash_value(&m_locks, - hash_value, + mdl_key->hash_value(), mdl_key->ptr(), mdl_key->length()); if (lock) @@ -1085,7 +1077,8 @@ void MDL_map::remove(MDL_lock *lock) void MDL_map_partition::remove(MDL_lock *lock) { mysql_mutex_lock(&m_mutex); - my_hash_delete(&m_locks, (uchar*) lock); + my_hash_delete_using_hash_value(&m_locks, lock->key.hash_value(), + (uchar*) lock); /* To let threads holding references to the MDL_lock object know that it was moved to the list of unused objects or destroyed, we increment the version === modified file 'sql/mdl.h' --- a/sql/mdl.h 2013-12-16 08:26:20 +0000 +++ b/sql/mdl.h 2014-02-14 12:25:41 +0000 @@ -347,12 +347,17 @@ class MDL_key m_ptr - 1); m_length= static_cast<uint16>(strmake(m_ptr + m_db_name_length + 2, name, NAME_LEN) - m_ptr + 1); + ulong nr2= 4; + m_hash_value= 1; + my_charset_bin.coll->hash_sort(&my_charset_bin, (uchar*) m_ptr, m_length, + &m_hash_value, &nr2); } void mdl_key_init(const MDL_key *rhs) { memcpy(m_ptr, rhs->m_ptr, rhs->m_length); m_length= rhs->m_length; m_db_name_length= rhs->m_db_name_length; + m_hash_value= rhs->m_hash_value; } bool is_equal(const MDL_key *rhs) const { @@ -392,10 +397,15 @@ class MDL_key { return & m_namespace_to_wait_state_name[(int)mdl_namespace()]; } + ulong hash_value() const + { + return m_hash_value; + } private: uint16 m_length; uint16 m_db_name_length; + ulong m_hash_value; char m_ptr[MAX_MDLKEY_LENGTH]; static PSI_stage_info m_namespace_to_wait_state_name[NAMESPACE_END]; private: === modified file 'strings/ctype-bin.c' --- a/strings/ctype-bin.c 2013-11-20 11:05:39 +0000 +++ b/strings/ctype-bin.c 2014-02-14 12:25:41 +0000 @@ -277,7 +277,9 @@ void my_hash_sort_8bit_bin(CHARSET_INFO ulong *nr1, ulong *nr2) { const uchar *pos = key; - + ulong tmp1= *nr1; + ulong tmp2= *nr2; + /* Remove trailing spaces. We have to do this to be able to compare 'A ' and 'A' as identical @@ -286,10 +288,13 @@ void my_hash_sort_8bit_bin(CHARSET_INFO for (; pos < (uchar*) key ; pos++) { - nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * - ((uint)*pos)) + (nr1[0] << 8); - nr2[0]+=3; + tmp1^= (ulong) ((((uint) tmp1 & 63) + tmp2) * + ((uint) *pos)) + (tmp1 << 8); + tmp2+= 3; } + + *nr1= tmp1; + *nr2= tmp2; } @@ -297,15 +302,20 @@ void my_hash_sort_bin(CHARSET_INFO *cs _ const uchar *key, size_t len,ulong *nr1, ulong *nr2) { const uchar *pos = key; - + ulong tmp1= *nr1; + ulong tmp2= *nr2; + key+= len; - + for (; pos < (uchar*) key ; pos++) { - nr1[0]^=(ulong) ((((uint) nr1[0] & 63)+nr2[0]) * - ((uint)*pos)) + (nr1[0] << 8); - nr2[0]+=3; + tmp1^= (ulong) ((((uint) tmp1 & 63) + tmp2) * + ((uint) *pos)) + (tmp1 << 8); + tmp2+= 3; } + + *nr1= tmp1; + *nr2= tmp2; } _______________________________________________ commits mailing list commits(a)mariadb.org https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits ----- End forwarded message -----

1 1

[Maria-developers] Buildbot: 10.0-mroonga and 10.0-spider
by Alexander Barkov 18 Feb '14

18 Feb '14

Hello Daniel, Kristian, Sergei, Can you please add 10.0-mroonga and 10.0-spider into BuildBot? Thanks.

1 1

[Maria-developers] Fwd: [debian-mysql] mariadb-5.5_5.5.35-1_amd64.changes ACCEPTED into unstable
by Otto Kekäläinen 18 Feb '14

18 Feb '14

FYI, my 5.5.35 just got uploaded to Debian by James Page. Next time .36 is released I'll try to get the upload done in 1-2 days after release. This of course if you help me a little bit by setting up the discussed build bots so that Debian is part of your QA and if you accept to merge my debian/* upstream so that there will be less "delta" per release to look at. ---------- Forwarded message ---------- From: Debian FTP Masters <ftpmaster(a)ftp-master.debian.org> Date: 2014-02-18 11:21 GMT+02:00 Subject: [debian-mysql] mariadb-5.5_5.5.35-1_amd64.changes ACCEPTED into unstable To: Debian MySQL Maintainers <pkg-mysql-maint(a)lists.alioth.debian.org>, James Page <jamespage(a)debian.org> Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Format: 1.8 Date: Mon, 17 Feb 2014 16:51:52 +0000 Source: mariadb-5.5 Binary: libmariadbclient18 libmariadbd-dev libmariadbclient-dev mariadb-common mariadb-client-core-5.5 mariadb-client-5.5 mariadb-server-core-5.5 mariadb-test-5.5 mariadb-server-5.5 mariadb-server mariadb-client mariadb-test Architecture: source all amd64 Version: 5.5.35-1 Distribution: unstable Urgency: low Maintainer: Debian MySQL Maintainers <pkg-mysql-maint(a)lists.alioth.debian.org> Changed-By: James Page <jamespage(a)debian.org> Description: libmariadbclient-dev - MariaDB database development files libmariadbclient18 - MariaDB database client library libmariadbd-dev - MariaDB embedded database development files mariadb-client - MariaDB database client (metapackage depending on the latest vers mariadb-client-5.5 - MariaDB database client binaries mariadb-client-core-5.5 - MariaDB database core client binaries mariadb-common - MariaDB common metapackage mariadb-server - MariaDB database server (metapackage depending on the latest vers mariadb-server-5.5 - MariaDB database server binaries mariadb-server-core-5.5 - MariaDB database core server files mariadb-test - MariaDB database regression test suite (metapackage for the lates mariadb-test-5.5 - MariaDB database regression test suite Closes: 732967 733002 734426 735284 736480 737597 Changes: mariadb-5.5 (5.5.35-1) unstable; urgency=low . [ Otto Kekäläinen ] * New upstream release, fixing the following security issues: - Buffer overflow in client/mysql.cc (Closes: #737597). - CVE-2014-0001 - http://www.oracle.com/technetwork/topics/security/cpujan2014-1972949.html - CVE-2013-5891 - CVE-2013-5908 - CVE-2014-0386 - CVE-2014-0393 - CVE-2014-0401 - CVE-2014-0402 - CVE-2014-0412 - CVE-2014-0420 - CVE-2014-0437 * Upstream https://mariadb.atlassian.net/browse/MDEV-4902 fixes compatibility with Bison 3.0 (Closes: #733002) * Updated Russian debconf translation (Closes: #734426) * Updated Japanese debconf translation (Closes: #735284) * Updated French debconf translation (Closes: #736480) * Renamed SONAME properly (Closes: #732967) -- Otto Kekäläinen +358 44 566 2204 http://seravo.fi/

1 0

[Maria-developers] Plugin init()/deinit() call convention
by Sergey Vojtovich 17 Feb '14

17 Feb '14

Hi Sergei, IIRC during early days of plugins framework there was a strict convention when plugin deinit() function must be called. Specifically only after successful call to init() function. I'm now fixing a bug in related code (5.5) and noticed that: - deinit() may (or may not) be called without prior call to init() - deinit() may (or may not) be called with prior failed call to init() Do you think the above is correct? Thanks, Sergey

2 1

[Maria-developers] system variable value
by Rich Prohaska 17 Feb '14

17 Feb '14

I have a ULONGLONG system variable in my storage engine, and I set its value to '-1' on the mysqld command line. Its value gets set to all ones without any warnings or errors. The number conversion functions just cast between longlong and ulonglong types without regard to the sign of the number. Is this correct behavior?

2 1

[Maria-developers] Problems installing mariadb published debian packages when using tmpfs for /tmp
by Andrew McDonnell 17 Feb '14

17 Feb '14

Hiya, I followed the instructions here: https://downloads.mariadb.org/mariadb/repositories/#mirror=aarnet_pty_ltd&d… cluminating with: apt-get install mariadb-server mariadb-client -t wheezy and eventually after almost everything appears to have worked, I get a fail starting mysqld. (Log follows after) To summarise the log below, my interpetation of the errors is: * mysql doesnt like tmpfs * I am using tmpfs for /tmp. But the ibdata files getcreated in /var/lib/mysql which is not on tmpfs. So I dont understand what is happening here... * I am running zfs. Could be part of the problem? So I set innodb_data_home_dir = /path/to/something/on/ext4, then chown mysql:mysql /path/to/something/on/ext4 And fail with "Cannot create ./ib_logfile101" So I reverted my change to the location and instead tried using innodb_flush_method = O_DSYNC (which seems to default to O_DIRECT) This time things moved a little further, failing instead at 'Setting log file ./ib_logfile1 size to 48 MB 2014-02-16 21:51:39 7f03b252b780 InnoDB: Operating system error number 22 in a file operation.' Now I have managed to build mariadb from source and run without these problems. So there seems to be something tricky needed mariadb 10 to run in Debian? This on a wheezy 7.2 amd64 system. ---- Long trace follows ---- So I noted that mysql-common remained in the system, so I apt-get purged it (not just removed) and tried again. Purging this took out mariadb which obviously seems to have mysql-common as a dependency, so they all got a reinstalling. Which drags back in mysql-common, but this time as a 10.0, the one that got purged was 5.5.x This time I had the same errors, plus the following as well: 140216 21:22:08 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway 140216 21:22:08 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 I noticed then that /var/log/mysql.err was empty, oddly. So if I then manually run mysqld-safe --syslog: Feb 16 21:31:05 atlantis4 mysqld_safe: Starting mysqld daemon with databases from /var/lib/mysql Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: The InnoDB memory heap is disabled Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Not e] InnoDB: Compressed tables use zlib 1.2.7 Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Using Linux native AIO Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Not using CPU crc32 instructions Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Initializing buffer pool, size = 256.0M Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] InnoDB: Completed initialization of buffer pool Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Plugin 'InnoDB' init function returned error. Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] Plugin 'FEEDBACK' is disabled. Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Unknown/unsupported storage engine: InnoDB Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [ERROR] Aborting Feb 16 21:31:05 atlantis4 mysqld: Feb 16 21:31:05 atlantis4 mysqld: 140216 21:31:05 [Note] /usr/sbin/mysqld: Shutdown complete Feb 16 21:31:05 atlantis4 mysqld: Feb 16 21:31:05 atlantis4 mysqld_safe: mysqld from pid file /var/run/mysqld/mysqld.pid ended (END) So I deleted /var/log/mysql and reran mysql_installdb. # mysql_install_db Installing MariaDB/MySQL system tables in '/var/lib/mysql' ... 140216 21:33:12 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:33:12 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:33:12 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:33:12 [Note] InnoDB: Using Linux native AIO 140216 21:33:12 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:33:12 [Note] InnoDB: Initializing buffer pool, size = 256.0M 140216 21:33:12 [Note] InnoDB: Completed initialization of buffer pool 140216 21:33:12 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: CREATE: Invalid argument, continuing anyway 140216 21:33:12 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 140216 21:33:12 [Note] InnoDB: The first specified data file ./ibdata1 did not exist: a new database to be created! 140216 21:33:12 [Note] InnoDB: Setting file ./ibdata1 size to 12 MB 140216 21:33:12 [Note] InnoDB: Database physically writes the file full: wait... 140216 21:33:12 [Note] InnoDB: Setting log file ./ib_logfile101 size to 48 MB 140216 21:33:12 [Note] InnoDB: Setting log file ./ib_logfile1 size to 48 MB 140216 21:33:12 [ERROR] InnoDB: Failed to set O_DIRECT on file ./ibdata1: OPEN: Invalid argument, continuing anyway 140216 21:33:12 [ERROR] InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 2014-02-16 21:33:12 7f66ea899780 InnoDB: Operating system error number 22 in a file operation. InnoDB: Error number 22 means 'Invalid argument'. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.6/en/operating-system-error-codes.html 140216 21:33:12 [ERROR] InnoDB: File ./ib_logfile101: 'aio write' returned OS error 122. Cannot continue operation Installation of system tables failed! Examine the logs in /var/lib/mysql for more information. <snipped> Errors after setting innodb_data_home_dir = /scratch/mysql # chown -R mysql:mysql /scratch/mysql/ root@atlantis4:/scratch# mysql_install_db Installing MariaDB/MySQL system tables in '/var/lib/mysql' ... 140216 21:47:44 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:47:44 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:47:44 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:47:44 [Note] InnoDB: Using Linux native AIO 140216 21:47:44 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:47:44 [Note] InnoDB: Initializing buffer pool, size = 256.0M 140216 21:47:44 [Note] InnoDB: Completed initialization of buffer pool 140216 21:47:44 [Note] InnoDB: The first specified data file /scratch/mysql/ibdata1 did not exist: a new database to be created! 140216 21:47:44 [Note] InnoDB: Setting file /scratch/mysql/ibdata1 size to 12 MB 140216 21:47:44 [Note] InnoDB: Database physically writes the file full: wait... 140216 21:47:44 [ERROR] InnoDB: Cannot create ./ib_logfile101 140216 21:47:44 [ERROR] Plugin 'InnoDB' init function returned error. 140216 21:47:44 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140216 21:47:44 [ERROR] Unknown/unsupported storage engine: InnoDB 140216 21:47:44 [ERROR] Aborting --- Log trace of first failed install follows --- Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libmariadbclient18 libmysqlclient18 mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server-10.0 mariadb-server-core-10.0 Suggested packages: tinyca mariadb-test The following packages will be REMOVED: mysql-client-5.5 mysql-server-core-5.5Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libmariadbclient18 libmysqlclient18 mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server-10.0 mariadb-server-core-10.0 Suggested packages: tinyca mariadb-test The following packages will be REMOVED: mysql-client-5.5 mysql-server-core-5.5 The following NEW packages will be installed: libmariadbclient18 mariadb-client mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server mariadb-server-10.0 mariadb-server-core-10.0 The following packages will be upgraded: libmysqlclient18 1 upgraded, 8 newly installed, 2 to remove and 147 not upgraded. Need to get 36.2 MB of archives. After this operation, 65.4 MB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-common all 10.0.8+maria-1~wheezy [3,310 B] Get:2 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmysqlclient18 amd64 10.0.8+maria-1~wheezy [2,966 B] Get:3 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmariadbclient18 amd64 10.0.8+maria-1~wheezy [941 kB] Get:4 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-core-10.0 amd64 10.0.8+maria-1~wheezy [1,993 kB] Get:5 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-10.0 amd64 10.0.8+maria-1~wheezy [5,593 kB] Get:6 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-core-10.0 amd64 10.0.8+maria-1~wheezy [6,096 kB] Get:7 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-10.0 amd64 10.0.8+maria-1~wheezy [21.6 MB] Get:8 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client all 10.0.8+maria-1~wheezy [2,874 B] Get:9 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server all 10.0.8+maria-1~wheezy [3,004 B] Fetched 36.2 MB in 2min 8s (281 kB/s) Preconfiguring packages ... (Reading database ... 358195 files and directories currently installed.) Removing mysql-client-5.5 ... Removing mysql-server-core-5.5 ... Processing triggers for man-db ... Selecting previously unselected package mariadb-common. (Reading database ... 358053 files and directories currently installed.) Unpacking mariadb-common (from .../mariadb-common_10.0.8+maria-1~wheezy_all.deb) ... Preparing to replace libmysqlclient18:amd64 5.5.31+dfsg-0+wheezy1 (using .../libmysqlclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Unpacking replacement libmysqlclient18 ... Selecting previously unselected package libmariadbclient18. Unpacking libmariadbclient18 (from .../libmariadbclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-core-10.0. Unpacking mariadb-client-core-10.0 (from .../mariadb-client-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-10.0. Unpacking mariadb-client-10.0 (from .../mariadb-client-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-server-core-10.0. Unpacking mariadb-server-core-10.0 (from .../mariadb-server-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Processing triggers for man-db ... Processing triggers for menu ... Setting up mariadb-common (10.0.8+maria-1~wheezy) ... Selecting previously unselected package mariadb-server-10.0. (Reading database ... 358190 files and directories currently installed.) Unpacking mariadb-server-10.0 (from .../mariadb-server-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client. Unpacking mariadb-client (from .../mariadb-client_10.0.8+maria-1~wheezy_all.deb) ... Selecting previously unselected package mariadb-server. Unpacking mariadb-server (from .../mariadb-server_10.0.8+maria-1~wheezy_all.deb) ... Processing triggers for man-db ... Setting up libmysqlclient18 (10.0.8+maria-1~wheezy) ... Setting up libmariadbclient18 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-10.0 (10.0.8+maria-1~wheezy) ... [ ok ] Stopping MariaDB database server: mysqld. 140216 21:14:37 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:14:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:14:37 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:14:37 [Note] InnoDB: Using Linux native AIO 140216 21:14:37 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:14:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M 140216 21:14:37 [Note] InnoDB: Completed initialization of buffer pool 140216 21:14:37 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! 140216 21:14:37 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! 140216 21:14:37 [ERROR] Plugin 'InnoDB' init function returned error. 140216 21:14:37 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140216 21:14:37 [Note] Plugin 'FEEDBACK' is disabled. 140216 21:14:37 [ERROR] Missing system table mysql.roles_mapping; please run mysql_upgrade to create it [FAIL] Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed! invoke-rc.d: initscript mysql, action "start" failed. dpkg: error processing mariadb-server-10.0 (--configure): subprocess installed post-installation script returned error exit status 1 Setting up mariadb-client (10.0.8+maria-1~wheezy) ... dpkg: dependency problems prevent configuration of mariadb-server: mariadb-server depends on mariadb-server-10.0 (= 10.0.8+maria-1~wheezy); however: Package mariadb-server-10.0 is not configured yet. dpkg: error processing mariadb-server (--configure): dependency problems - leaving unconfigured Processing triggers for menu ... Errors were encountered while processing: mariadb-server-10.0 mariadb-server localepurge: Disk space freed in /usr/share/locale: 0 KiB localepurge: Disk space freed in /usr/share/man: 0 KiB localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB localepurge: Disk space freed in /usr/share/omf: 0 KiB localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB Total disk space freed by localepurge: 0 KiB E: Sub-process /usr/bin/dpkg returned an error code (1) The following NEW packages will be installed: libmariadbclient18 mariadb-client mariadb-client-10.0 mariadb-client-core-10.0 mariadb-common mariadb-server mariadb-server-10.0 mariadb-server-core-10.0 The following packages will be upgraded: libmysqlclient18 1 upgraded, 8 newly installed, 2 to remove and 147 not upgraded. Need to get 36.2 MB of archives. After this operation, 65.4 MB of additional disk space will be used. Do you want to continue [Y/n]? Get:1 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-common all 10.0.8+maria-1~wheezy [3,310 B] Get:2 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmysqlclient18 amd64 10.0.8+maria-1~wheezy [2,966 B] Get:3 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main libmariadbclient18 amd64 10.0.8+maria-1~wheezy [941 kB] Get:4 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-core-10.0 amd64 10.0.8+maria-1~wheezy [1,993 kB] Get:5 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client-10.0 amd64 10.0.8+maria-1~wheezy [5,593 kB] Get:6 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-core-10.0 amd64 10.0.8+maria-1~wheezy [6,096 kB] Get:7 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server-10.0 amd64 10.0.8+maria-1~wheezy [21.6 MB] Get:8 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-client all 10.0.8+maria-1~wheezy [2,874 B] Get:9 http://mirror.aarnet.edu.au/pub/MariaDB/repo/10.0/debian/ wheezy/main mariadb-server all 10.0.8+maria-1~wheezy [3,004 B] Fetched 36.2 MB in 2min 8s (281 kB/s) Preconfiguring packages ... (Reading database ... 358195 files and directories currently installed.) Removing mysql-client-5.5 ... Removing mysql-server-core-5.5 ... Processing triggers for man-db ... Selecting previously unselected package mariadb-common. (Reading database ... 358053 files and directories currently installed.) Unpacking mariadb-common (from .../mariadb-common_10.0.8+maria-1~wheezy_all.deb) ... Preparing to replace libmysqlclient18:amd64 5.5.31+dfsg-0+wheezy1 (using .../libmysqlclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Unpacking replacement libmysqlclient18 ... Selecting previously unselected package libmariadbclient18. Unpacking libmariadbclient18 (from .../libmariadbclient18_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-core-10.0. Unpacking mariadb-client-core-10.0 (from .../mariadb-client-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client-10.0. Unpacking mariadb-client-10.0 (from .../mariadb-client-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-server-core-10.0. Unpacking mariadb-server-core-10.0 (from .../mariadb-server-core-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Processing triggers for man-db ... Processing triggers for menu ... Setting up mariadb-common (10.0.8+maria-1~wheezy) ... Selecting previously unselected package mariadb-server-10.0. (Reading database ... 358190 files and directories currently installed.) Unpacking mariadb-server-10.0 (from .../mariadb-server-10.0_10.0.8+maria-1~wheezy_amd64.deb) ... Selecting previously unselected package mariadb-client. Unpacking mariadb-client (from .../mariadb-client_10.0.8+maria-1~wheezy_all.deb) ... Selecting previously unselected package mariadb-server. Unpacking mariadb-server (from .../mariadb-server_10.0.8+maria-1~wheezy_all.deb) ... Processing triggers for man-db ... Setting up libmysqlclient18 (10.0.8+maria-1~wheezy) ... Setting up libmariadbclient18 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-client-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-core-10.0 (10.0.8+maria-1~wheezy) ... Setting up mariadb-server-10.0 (10.0.8+maria-1~wheezy) ... [ ok ] Stopping MariaDB database server: mysqld. 140216 21:14:37 [Note] InnoDB: The InnoDB memory heap is disabled 140216 21:14:37 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 140216 21:14:37 [Note] InnoDB: Compressed tables use zlib 1.2.7 140216 21:14:37 [Note] InnoDB: Using Linux native AIO 140216 21:14:37 [Note] InnoDB: Not using CPU crc32 instructions 140216 21:14:37 [Note] InnoDB: Initializing buffer pool, size = 128.0M 140216 21:14:37 [Note] InnoDB: Completed initialization of buffer pool 140216 21:14:37 [ERROR] InnoDB: auto-extending data file ./ibdata1 is of a different size 640 pages (rounded down to MB) than specified in the .cnf file: initial 768 pages, max 0 (relevant if non-zero) pages! 140216 21:14:37 [ERROR] InnoDB: Could not open or create the system tablespace. If you tried to add new data files to the system tablespace, and it failed here, you should now edit innodb_data_file_path in my.cnf back to what it was, and remove the new ibdata files InnoDB created in this failed attempt. InnoDB only wrote those files full of zeros, but did not yet use them in any way. But be careful: do not remove old data files which contain your precious data! 140216 21:14:37 [ERROR] Plugin 'InnoDB' init function returned error. 140216 21:14:37 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 140216 21:14:37 [Note] Plugin 'FEEDBACK' is disabled. 140216 21:14:37 [ERROR] Missing system table mysql.roles_mapping; please run mysql_upgrade to create it insserv: warning: script 'K01fcron' missing LSB tags and overrides insserv: warning: script 'fcron' missing LSB tags and overrides [FAIL] Starting MariaDB database server: mysqld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . failed! invoke-rc.d: initscript mysql, action "start" failed. dpkg: error processing mariadb-server-10.0 (--configure): subprocess installed post-installation script returned error exit status 1 Setting up mariadb-client (10.0.8+maria-1~wheezy) ... dpkg: dependency problems prevent configuration of mariadb-server: mariadb-server depends on mariadb-server-10.0 (= 10.0.8+maria-1~wheezy); however: Package mariadb-server-10.0 is not configured yet. dpkg: error processing mariadb-server (--configure): dependency problems - leaving unconfigured Processing triggers for menu ... Errors were encountered while processing: mariadb-server-10.0 mariadb-server localepurge: Disk space freed in /usr/share/locale: 0 KiB localepurge: Disk space freed in /usr/share/man: 0 KiB localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB localepurge: Disk space freed in /usr/share/omf: 0 KiB localepurge: Disk space freed in /usr/share/doc/kde/HTML: 0 KiB Total disk space freed by localepurge: 0 KiB E: Sub-process /usr/bin/dpkg returned an error code (1)

3 4

[Maria-developers] Open Knowledge Base questions
by Ian Gilfillan 17 Feb '14

17 Feb '14

There are a few open questions on the Knowledge Base - some have been around a while, and it would be great if anyone can answer them: 1) Licensing question about MariaDB and dot net Connector: https://mariadb.com/kb/en/licencing-of-mariadb-and-mysql-dot-net-connector/ 2) Query on whether the MariaDB Java Client can support Java 1.5 https://mariadb.com/kb/en/java-15-and-mariadb-connector/ The answer's presumably no, but a 1-liner on why not would be nice to have 3) Another Java client query: https://mariadb.com/kb/en/client-for-mysql-zerodatetimebehaviorconverttonul… 4) A couple of Galera queries: https://mariadb.com/kb/en/asynchronous-replication-with-galera-cluster/ https://mariadb.com/kb/en/simple-cluster-two-nodes-error/ https://mariadb.com/kb/en/strange-ssl-messages-in-error-log/ thanks, ian

1 0

Re: [Maria-developers] uint6korr optimization
by Michael Widenius 16 Feb '14

16 Feb '14

Hi! >>>>> "Alexey" == Alexey Botchkov <holyfoot(a)askmonty.org> writes: Alexey> Hi, Monty. Alexey> I've looked at that part of the code, and tried to make the improved Alexey> versions of uint6korr and mi_uint6korr. Alexey> The small program attached that benchmarks these. Alexey> Depending on enabled macros it loops uint6korr, hf_uint6korr, Alexey> mi_uint6korr and hf_mi_uint6korr respectively. It performs 2 loops on Alexey> each functions first runs it once, the second - twice, so we can Alexey> calculate how much time was spent on the operation itself. Alexey> The results i got so far are: Alexey> elapsed 103 seconds on korr6-1 Alexey> elapsed 190 seconds on korr6-2 Alexey> elapsed 50 seconds on hf_korr6-1 Alexey> elapsed 79 seconds on hf_korr6-2 Alexey> elapsed 106 seconds on mi6-1 Alexey> elapsed 195 seconds on mi6-2 Alexey> elapsed 56 seconds on hf_mi6B-1 Alexey> elapsed 88 seconds on hf_mi6-2 Alexey> So the Alexey> hf_uint6korr is 3 times faster than uint6korr. Alexey> hf_mi_uint6korr is 2.8 times faster than mi_uint6korr. Alexey> You're welcome to check the code out. Thanks. What is important is to get fast versions of mi_uint3korr (Used a lot in ma_dynrec.c and gis) mi_uint4korr mi_uint5korr mi_uint6korr mi_uint7korr mi_uint8korr (Used for some variables) uint5korr uint6korr (Used a lot in Aria) uint8korr (I am including the full test so that anyone can comment upon this) ---------------------------------------------------------------------- #include <stdio.h> #include <time.h> #include <malloc.h> #define TEST_KORR6 #define TEST_HF_KORR6 #define TEST_MI6 #define TEST_HF_MI6 #define uint6korr(A) ((ulonglong)(((uint32) ((uchar) (A)[0])) + \ (((uint32) ((uchar) (A)[1])) << 8) + \ (((uint32) ((uchar) (A)[2])) << 16) + \ (((uint32) ((uchar) (A)[3])) << 24)) + \ (((ulonglong) ((uchar) (A)[4])) << 32) + \ (((ulonglong) ((uchar) (A)[5])) << 40)) #define mi_uint6korr(A) ((ulonglong)(((uint32) (((const uchar*) (A))[5])) +\ (((uint32) (((const uchar*) (A))[4])) << 8) +\ (((uint32) (((const uchar*) (A))[3])) << 16) +\ (((uint32) (((const uchar*) (A))[2])) << 24)) +\ (((ulonglong) (((uint32) (((const uchar*) (A))[1])) +\ (((uint32) (((const uchar*) (A))[0]) << 8)))) <<\ 32)) #define hf_uint6korr(A) (((ulonglong) ((uint32 *) (A))[0]) + (((ulonglong) ((uint16 *) (A))[2]) << 32)) #define hf_mi_uint6korr(src, dest) \ __asm__ ( \ "bswapq %1;" \ "mov %1, %0;" \ :"=r"(dest) \ :"r"(hf_uint6korr(src)<<16) \ : \ ) typedef unsigned long long int ulonglong; typedef unsigned int uint32; typedef unsigned char uchar; typedef unsigned short uint16; time_t t0, t1; ulonglong i; #define GM 10000000000LL #define BAS 2000000 int main() { ulonglong *pb, *pb2; char *art, *art2; ulonglong ci; art= malloc(6*BAS); pb= malloc(sizeof(ulonglong)*BAS); for (i=0; i<6*BAS; i++) art[i]= (char)i; art2= malloc(6*BAS); pb2= malloc(sizeof(ulonglong)*BAS); for (i=0; i<6*BAS; i++) art2[i]= (char)i; #ifdef TEST_KORR6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= uint6korr(art+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on korr6-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= uint6korr(art+ci*6); pb2[ci]= uint6korr(art2+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on korr6-2\n", t1 - t0); #endif /*KORR6*/ #ifdef TEST_HF_KORR6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= hf_uint6korr(art+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on hf_korr6-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= hf_uint6korr(art+ci*6); pb2[ci]= hf_uint6korr(art2+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on hf_korr6-2\n", t1 - t0); #endif /*HF_KORR6*/ #ifdef TEST_MI6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= mi_uint6korr(art+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on mi6-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; pb[ci]= mi_uint6korr(art+ci*6); pb2[ci]= mi_uint6korr(art2+ci*6); ci++; } t1= time(0); printf("elapsed %d seconds on mi6-2\n", t1 - t0); #endif /*MI6*/ #ifdef TEST_HF_MI6 ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; hf_mi_uint6korr(art+ci*6, pb[ci]); ci++; } t1= time(0); printf("elapsed %d seconds on hf_mi6B-1\n", t1 - t0); ci= 0; t0= time(0); for (i=0; i<GM; i++) { if (ci >= BAS) ci= 0; hf_mi_uint6korr(art+ci*6, pb[ci]); hf_mi_uint6korr(art2+ci*6, pb2[ci]); ci++; } t1= time(0); printf("elapsed %d seconds on hf_mi6-2\n", t1 - t0); #endif /*HF_MI6*/ return 0; } Looks ok. Did you try with: #define hf_uint6korr(A) (*((uint64 *) A) & 0xffffffffffffLL) That may be faster, with the extra cost problem of reading 2 bytes extra, so this only safe to use if one knows that there is a few extra bytes in the buffer. Can you do a patch to my_global.h and myisampack and add the new functions there. What to do: - All improvements for now only for x64 architecture - Replace uint6korr(A) and any other function that can be improved without reading extra bytes with a faster version. - Improve with faster variants: mi_uint3korr mi_uint4korr mi_uint5korr mi_uint6korr mi_uint7korr mi_uint8korr uint5korr uint6korr uint8korr If the above suggested version of uint6korr() that reads extra bytes is notable faster, add a function: uint6korr_unsafe() Which of course should map to uint6korr for other architectures. ok? Regards, Monty

4 5

[Maria-developers] Potential participation in Google Summer of Code 2014
by Colin Charles 15 Feb '14

15 Feb '14

Hi! We have applied to be part of the Google Summer of Code 2014 project, and hope to gain some new contributors. If you are on this list and think you can be a mentor for a project, please consider writing a note at: https://mariadb.com/kb/en/google-summer-of-code-2014/ I think the aim for the GSoC students code should be for 10.1 inclusion If you have any queries, don't hesitate to ask me about them, I'm happy to help. Typically mentors need about 4 hours or so per week to assist the student in seeing their project become a reality I encourage many to participate as its a rewarding experience. In 2013, we did participate, and got 3 features out of it: SQL ROLES, PCRE regular expressions, and a Kerberos authentication plugin Looking forward to seeing more happen in 2014! (here's hoping we get accepted into GSoC 2014 of course!) cheers, -colin -- Colin Charles, Chief Evangelist MariaDB | t: +6-012-204-3201 | Skype: colincharles

1 0

Re: [Maria-developers] Rev 4056: MDEV-5616 - Deadlock between CREATE/DROP FUNCTION and SELECT from view
by Sergei Golubchik 13 Feb '14

13 Feb '14

Hi, Sergey! Ok to push. A couple of comments below. On Feb 07, Sergey Vojtovich wrote: > revno: 4056 > revision-id: svoj(a)mariadb.org-20140207100451-8pnzn85pjjwvwfs4 > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5616 > timestamp: Fri 2014-02-07 14:04:51 +0400 > message: > MDEV-5616 - Deadlock between CREATE/DROP FUNCTION and SELECT from view > > Deadlock happened due to mixed lock order. > CREATE/DROP function: wrlock(THR_LOCK_udf) -> lock(LOCK_open) > SELECT from view: lock(LOCK_open) -> rdlock(THR_LOCK_udf) > > Fixed CREATE/DROP function so that LOCK_open does not intersect with > wrlock(THR_LOCK_udf). > > 10.0 is not affected: it doesn't hold LOCK_open while opening view. I'm pretty sure it'll auto-merge and nobody will remember this warning at that time. So this patch will be in 10.0. Perhaps you should add #if MYSQL_VERSION_ID > 50600 #error don't merge into 10.0 #endif ? Or, may be, it's not a big deal to have it in 10.0... > === modified file 'sql/sql_udf.cc' > --- a/sql/sql_udf.cc 2012-03-27 23:04:46 +0000 > +++ b/sql/sql_udf.cc 2014-02-07 10:04:51 +0000 > @@ -466,7 +467,11 @@ int mysql_create_function(THD *thd,udf_f > if ((save_binlog_row_based= thd->is_current_stmt_binlog_format_row())) > thd->clear_current_stmt_binlog_format_row(); > > + tables.init_one_table("mysql", 5, "func", 4, "func", TL_WRITE); I know it's a old line that you've moved and it's a matter of taste anyway, so up to you, but generally I prefer to see STRING_WITH_LEN here. It 1) makes a certain class of typos impossible; 2) documents the code, one doesn't need to think what these 4 and 5 stand for. Regards, Sergei

2 1

Re: [Maria-developers] Rev 3967: MDEV-5597 - Reduce usage of LOCK_open: LOCK_flush
by Sergei Golubchik 12 Feb '14

12 Feb '14

Hi, Sergey! On Jan 31, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 3967 > revision-id: svoj(a)mariadb.org-20140131141943-fjyyih3h92lek62n > parent: svoj(a)mariadb.org-20140130124905-vy28zbs9swlpg8uq > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Fri 2014-01-31 18:19:43 +0400 > message: > MDEV-5597 - Reduce usage of LOCK_open: LOCK_flush > > Replaced LOCK_flush with per-share conditional variable. > === modified file 'sql/table_cache.cc' > --- a/sql/table_cache.cc 2014-01-30 12:49:05 +0000 > +++ b/sql/table_cache.cc 2014-01-31 14:19:43 +0000 > @@ -945,6 +949,7 @@ bool tdc_remove_table(THD *thd, enum_tdc > if ((share= tdc_delete_share(db, table_name))) > { > I_P_List <TABLE, TABLE_share> purge_tables; > + uint my_refs= 1; > > mysql_mutex_lock(&LOCK_open); > /* > @@ -969,28 +974,48 @@ bool tdc_remove_table(THD *thd, enum_tdc > if (kill_delayed_threads) > kill_delayed_threads_for_table(share); > > -#ifndef DBUG_OFF > - if (remove_type == TDC_RT_REMOVE_NOT_OWN) > + if (remove_type == TDC_RT_REMOVE_NOT_OWN || > + remove_type == TDC_RT_REMOVE_NOT_OWN_KEEP_SHARE) > { > TABLE_SHARE::All_share_tables_list::Iterator it(share->tdc.all_tables); > while ((table= it++)) > + { > + my_refs++; > DBUG_ASSERT(table->in_use == thd); > + } > } > -#endif > - > - mysql_rwlock_rdlock(&LOCK_flush); > + DBUG_ASSERT(share->tdc.all_tables.is_empty() || remove_type != TDC_RT_REMOVE_ALL); > mysql_mutex_unlock(&LOCK_open); > > while ((table= purge_tables.pop_front())) > intern_close_table(table); > - mysql_rwlock_unlock(&LOCK_flush); > > - DBUG_ASSERT(share->tdc.all_tables.is_empty() || remove_type != TDC_RT_REMOVE_ALL); > - tdc_release_share(share); > + if (remove_type != TDC_RT_REMOVE_UNUSED) > + { > + /* > + Even though current thread holds exclusive metadata lock on this share > + (asserted above), concurrent FLUSH TABLES threads may be in process of > + closing unused table instances belonging to this share. E.g.: > + thr1 (FLUSH TABLES): table= share->tdc.free_tables.pop_front(); > + thr1 (FLUSH TABLES): share->tdc.all_tables.remove(table); > + thr2 (ALTER TABLE): tdc_remove_table(); > + thr1 (FLUSH TABLES): intern_close_table(table); > + > + Current remove type assumes that all table instances (except for those > + that are owned by current thread) must be closed before > + thd_remove_table() returns. Wait for such tables here. > + > + Unfortunately TABLE_SHARE::wait_for_old_version() cannot be used here > + because it waits for all table instances, whereas we have to wait only > + for those that are not owned by current thread. > + */ > + mysql_mutex_lock(&share->tdc.LOCK_table_share); > + while (share->tdc.ref_count > my_refs) > + mysql_cond_wait(&share->tdc.COND_release, &share->tdc.LOCK_table_share); > + mysql_mutex_unlock(&share->tdc.LOCK_table_share); I'm sorry, I don't understand that at all. Why my_refs is only incremented in debug builds? In non-debug builds you wait until all tables but one are closed, in debug builds you may keep more than one table opened. You wait here on a condition, how do you know there's FLUSH TABLES (or anything at all) running that will signal this condition? > + } > > - /* Wait for concurrent threads to free unused objects. */ > - mysql_rwlock_wrlock(&LOCK_flush); > - mysql_rwlock_unlock(&LOCK_flush); > + tdc_release_share(share); > > found= true; > } Regards, Sergei

2 4

[Maria-developers] MariaDB config for Akonadi - suggestions?
by Sergey Petrunia 12 Feb '14

12 Feb '14

Hi, Daniel Vratil from Akonadi (a PIM manager for KDE) has asked me at FOSDEM about optimal MariaDB configuration for Akonadi. Some specific questions: * innodb_flush_log_at_trx_commit. Currently, Akonadi uses innodb_flush_log_at_trx_commit=2 which as far as I understand can cause up to 1 second of changes to be lost. Using value of 1 (always flush on commit) should be safer, but maybe it would put an unnecessary load on the system? Akonadi's use case has a bit different idea of what load is - there is only one person making changes, but the system is likely to be a laptop where one cares about battery life, etc. * innodb_buffer_pool_size=80M. The dataset size can vary from very small to up to 1-1.5Gb. Some users have very little data and complain that 80M is too much. Does anybody have an experience with using very small innodb_buffer_pool_size? Please find the full config file below: === Akonadi configuration file === # These settings can be adjusted using $HOME/.config/akonadi/mysql-local.conf # # Based on advice by Kris Köhntopp <kris(a)mysql.com> # [mysqld] # strict query parsing/interpretation # TODO: make Akonadi work with those settings enabled # sql_mode=strict_trans_tables,strict_all_tables,strict_error_for_division_by_zero,no_auto_create_user,no_auto_value_on_zero,no_engine_substitution,no_zero_date,no_zero_in_date,only_full_group_by,pipes_as_concat # sql_mode=strict_trans_tables # DEBUGGING: # log all queries, useful for debugging but generates an enormous amount of data # log=mysql.full # log queries slower than n seconds, log file name relative to datadir (for debugging only) # log_slow_queries=mysql.slow # long_query_time=1 # log queries not using indices, debug only, disable for production use # log_queries_not_using_indexes=1 # # mesure database size and adjust innodb_buffer_pool_size # SELECT sum(data_length) as bla, sum(index_length) as blub FROM information_schema.tables WHERE table_schema not in ("mysql", "information_schema"); # NOTES: # Keep Innob_log_waits and keep Innodb_buffer_pool_wait_free small (see show global status like "inno%", show global variables) #expire_logs_days=3 #sync_bin_log=0 # Use UTF-8 encoding for tables character_set_server=utf8 collation_server=utf8_general_ci # use InnoDB for transactions and better crash recovery default_storage_engine=innodb # memory pool InnoDB uses to store data dictionary information and other internal data structures (default:1M) # Deprecated in MySQL >= 5.6.3 innodb_additional_mem_pool_size=1M # memory buffer InnoDB uses to cache data and indexes of its tables (default:128M) # Larger values means less I/O innodb_buffer_pool_size=80M # Create a .ibd file for each table (default:0) innodb_file_per_table=1 # Write out the log buffer to the log file at each commit (default:1) innodb_flush_log_at_trx_commit=2 # Buffer size used to write to the log files on disk (default:1M for builtin, 8M for plugin) # larger values means less I/O innodb_log_buffer_size=1M # Size of each log file in a log group (default:5M) larger means less I/O but more time for recovery. innodb_log_file_size=64M # # error log file name, relative to datadir (default:hostname.err) log_error=mysql.err # print warnings and connection errors (default:1) log_warnings=2 # Convert table named to lowercase lower_case_table_names=1 # Maximum size of one packet or any generated/intermediate string. (default:1M) max_allowed_packet=32M # Maximum simultaneous connections allowed (default:100) max_connections=256 # The two options below make no sense with prepared statements and/or transactions # (make sense when having the same query multiple times) # Memory allocated for caching query results (default:0 (disabled)) query_cache_size=0 # Do not cache results (default:1) query_cache_type=0 # Do not use the privileges mechanisms skip_grant_tables # Do not listen for TCP/IP connections at all skip_networking # The number of open tables for all threads. (default:64) table_open_cache=200 # How many threads the server should cache for reuse (default:0) thread_cache_size=3 # wait 365d before dropping the DB connection (default:8h) wait_timeout=31536000 # We use InnoDB, so don't let MyISAM eat up memory key_buffer_size=16K [client] default-character-set=utf8 BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] Minor glitch when doing out of tree cmake build
by Andrew McDonnell 10 Feb '14

10 Feb '14

Hi, I like to build MariaDB in a separate directory to keep the source tree clean. This works for me as follows: cd path/to/maria/source mkdir mybuildir cd mybuildir cmake .. "-DWITH_PLUGIN_ARIA=1 (etc...)" make mysql-test/mysql-test-run --suite oqgraph (etc) However when I want to use this build to create a non-MTR database as follows: MARIA_HOME=path/to/maria/source MARIA_BUILD=path/to/maria/source/mybuilddir sh $MARIA_BUILD/scripts/mysql_install_db \ --srcdir=$MARIA_HOME \ --builddir=$MARIA_BUILD \ --datadir=path/to/data --defaults-file=... This fails with FATAL ERROR: Could not find maria/source/sql/share/english/errmsg.sys Different combinations of --srcdir and --builddir produce similar but different errors. I tracked down where the files are set to to lines 263..303 of scripts/mysql_install_db.sh >From my reading of the help: --builddir=path If using --srcdir with out-of-directory builds, you will need to set this to the location of the build directory where built files reside. --srcdir=path The path to the MariaDB source directory. This option uses the compiled binaries and support files within the source tree, useful for if you don't want to install MariaDB yet and just want to create the system tables. I was able to make the install script work with the following patch === modified file 'scripts/mysql_install_db.sh' --- scripts/mysql_install_db.sh 2014-02-03 14:22:39 +0000 +++ scripts/mysql_install_db.sh 2014-02-08 11:52:52 +0000 @@ -267,7 +267,7 @@ bindir="$basedir/client" extra_bindir="$basedir/extra" mysqld="$basedir/sql/mysqld" - langdir="$srcdir/sql/share/english" + langdir="$basedir/sql/share/english" pkgdatadir="$srcdir/scripts" scriptdir="$srcdir/scripts" elif test -n "$basedir" What I dont know enough about, is whether this breaks other scenarios? any advice appreciated, thanks, Andrew -- http://blog.oldcomputerjunk.net https://launchpad.net/~andymc73 https://github.com/andymc73 Twitter: @pastcompute GPG: http://www.andrewmcdonnell.net/gpg.html

2 3

Re: [Maria-developers] Rev 4056: MDEV-5607: Query cache destroys uninitialized rwlock
by Sergei Golubchik 10 Feb '14

10 Feb '14

Hi, Sanja! On Feb 08, sanja(a)askmonty.org wrote: > ------------------------------------------------------------ > revno: 4056 > revision-id: sanja(a)askmonty.org-20140208132448-qdkkpdncnya0tr6j > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-5607 > timestamp: Sat 2014-02-08 15:24:48 +0200 > message: > MDEV-5607: Query cache destroys uninitialized rwlock > > - Resize destroyed rw_lock twice, now it is prevented. > - Trash destroyed rw lock. > === modified file 'include/mysql/psi/mysql_thread.h' > --- a/include/mysql/psi/mysql_thread.h 2013-01-11 00:03:43 +0000 > +++ b/include/mysql/psi/mysql_thread.h 2014-02-08 13:24:48 +0000 > @@ -16,6 +16,8 @@ > #ifndef MYSQL_THREAD_H > #define MYSQL_THREAD_H > > +#include <my_valgrind.h> This is not ok. Files under include/mysql/ are Plugin API files, they should be clean from internal includes. You cannot include my_valgrind.h from there. Do it in my_pthread.h Regards, Sergei

2 1

[Maria-developers] Please merge 5.3 -> 5.5, mdev-5468
by Sergei Petrunia 10 Feb '14

10 Feb '14

Hello Igor, Your fix for mdev-5468 is the oldest fix in 5.3 that is not merged to 5.5. I've tried merging it. The changes in the code auto-merged, but after that the testsuite failed with crashes. Could you please merge mdev-5468 from 5.3 to 5.5? BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] Rev 4056: MDEV-5607: Query cache destroys uninitialized rwlock in file:///home/bell/maria/bzr/work-maria-5.5-MDEV-5607/
by Sergey Vojtovich 10 Feb '14

10 Feb '14

Hi Sanja, JFYI: while reporting this bug I came up with two questions that I couldn't answer quickly. Probably they make sense, if not just ignore them: 1. This code was introduced with https://bugs.launchpad.net/maria/+bug/782223, revision: wlad(a)montyprogram.com-20110514163720-rmico2qegtptjguk <quot> The callstack leading of "free" containing critical section is: mysqld!free my_no_flags_free Query_cache::free_cache Query_cache::resize fix_query_cache_size set_var::update sql_set_variables mysql_execute_command mysql_parse <quot> It means that this code was supposed to be executed exactly by Query_cache::resize(), where you disable it. Question: if this code is not supposed to be executed by ::resize(), is it needed at all? 2. In Query_cache::resize() I can see block-level locks are acquired with the following comment: <quot> Wait for all readers and writers to exit. When the list of all queries is iterated over with a block level lock, we are done. </quot> Isn't it needed in ::free_cache() also? Regards, Sergey On Sat, Feb 08, 2014 at 01:25:11PM +0000, sanja(a)askmonty.org wrote: > At file:///home/bell/maria/bzr/work-maria-5.5-MDEV-5607/ > > ------------------------------------------------------------ > revno: 4056 > revision-id: sanja(a)askmonty.org-20140208132448-qdkkpdncnya0tr6j > parent: elenst(a)wheezy-64.home-20140205102537-7ern5gfca6a6ojg3 > committer: sanja(a)askmonty.org > branch nick: work-maria-5.5-MDEV-5607 > timestamp: Sat 2014-02-08 15:24:48 +0200 > message: > MDEV-5607: Query cache destroys uninitialized rwlock > > - Resize destroyed rw_lock twice, now it is prevented. > - Trash destroyed rw lock. > === modified file 'include/my_valgrind.h' > --- a/include/my_valgrind.h 2012-03-22 11:31:09 +0000 > +++ b/include/my_valgrind.h 2014-02-08 13:24:48 +0000 > @@ -13,7 +13,8 @@ > along with this program; if not, write to the Free Software > Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ > > - > +#ifndef my_valgrind_h > +#define my_valgrind_h > /* Some defines to make it easier to use valgrind */ > #include <m_string.h> /* bfill */ > > @@ -45,3 +46,4 @@ > #define TRASH_FREE(A,B) TRASH_FILL(A,B,0x8F) > #define TRASH(A,B) TRASH_FREE(A,B) > > +#endif //my_valgrind_h > > === modified file 'include/mysql/psi/mysql_thread.h' > --- a/include/mysql/psi/mysql_thread.h 2013-01-11 00:03:43 +0000 > +++ b/include/mysql/psi/mysql_thread.h 2014-02-08 13:24:48 +0000 > @@ -16,6 +16,8 @@ > #ifndef MYSQL_THREAD_H > #define MYSQL_THREAD_H > > +#include <my_valgrind.h> > + > /** > @file mysql/psi/mysql_thread.h > Instrumentation helpers for mysys threads, mutexes, > @@ -714,6 +716,7 @@ static inline int inline_mysql_prlock_in > static inline int inline_mysql_rwlock_destroy( > mysql_rwlock_t *that) > { > + int res; > #ifdef HAVE_PSI_INTERFACE > if (likely(PSI_server && that->m_psi)) > { > @@ -721,7 +724,9 @@ static inline int inline_mysql_rwlock_de > that->m_psi= NULL; > } > #endif > - return rwlock_destroy(&that->m_rwlock); > + res= rwlock_destroy(&that->m_rwlock); > + TRASH(that, sizeof(*that)); > + return res; > } > > #ifndef DISABLE_MYSQL_PRLOCK_H > > === modified file 'mysql-test/r/query_cache.result' > --- a/mysql-test/r/query_cache.result 2013-10-16 13:07:25 +0000 > +++ b/mysql-test/r/query_cache.result 2014-02-08 13:24:48 +0000 > @@ -2077,6 +2077,21 @@ drop procedure p1; > drop table t1; > set GLOBAL query_cache_size=1355776; > SET GLOBAL userstat=default; > +# > +#MDEV-5607 Query cache destroys uninitialized rwlock > +# > +SET @global_query_cache_size = @@global.query_cache_size; > +SET @global_query_cache_type = @@global.query_cache_type; > +SET GLOBAL query_cache_type = default; > +SET GLOBAL query_cache_size = default; > +SET GLOBAL query_cache_type = ON; > +SET GLOBAL query_cache_size = 131072; > +CREATE TABLE t1(a INT); > +SELECT * FROM t1; > +a > +SET GLOBAL query_cache_size = @global_query_cache_size; > +SET GLOBAL query_cache_type = @global_query_cache_type; > +DROP TABLE t1; > End of 5.5 tests > restore defaults > SET GLOBAL query_cache_type= default; > > === modified file 'mysql-test/t/query_cache.test' > --- a/mysql-test/t/query_cache.test 2013-10-16 13:07:25 +0000 > +++ b/mysql-test/t/query_cache.test 2014-02-08 13:24:48 +0000 > @@ -1708,6 +1708,23 @@ drop table t1; > set GLOBAL query_cache_size=1355776; > SET GLOBAL userstat=default; > > +--echo # > +--echo #MDEV-5607 Query cache destroys uninitialized rwlock > +--echo # > +SET @global_query_cache_size = @@global.query_cache_size; > +SET @global_query_cache_type = @@global.query_cache_type; > +SET GLOBAL query_cache_type = default; > +SET GLOBAL query_cache_size = default; > +SET GLOBAL query_cache_type = ON; > +SET GLOBAL query_cache_size = 131072; > + > +CREATE TABLE t1(a INT); > +SELECT * FROM t1; > + > +SET GLOBAL query_cache_size = @global_query_cache_size; > +SET GLOBAL query_cache_type = @global_query_cache_type; > +DROP TABLE t1; > + > --echo End of 5.5 tests > > --echo restore defaults > > === modified file 'sql/sql_cache.cc' > --- a/sql/sql_cache.cc 2013-11-19 12:16:25 +0000 > +++ b/sql/sql_cache.cc 2014-02-08 13:24:48 +0000 > @@ -1326,6 +1326,7 @@ ulong Query_cache::resize(ulong query_ca > query->unlock_n_destroy(); > block= block->next; > } while (block != queries_blocks); > + queries_blocks= NULL; // avoid second destroying by free_cache > } > free_cache(); > > > === modified file 'storage/perfschema/ha_perfschema.cc' > --- a/storage/perfschema/ha_perfschema.cc 2012-03-27 23:04:46 +0000 > +++ b/storage/perfschema/ha_perfschema.cc 2014-02-08 13:24:48 +0000 > @@ -19,9 +19,9 @@ > */ > > #include "my_global.h" > +#include "sql_plugin.h" > #include "my_pthread.h" > #include "my_atomic.h" > -#include "sql_plugin.h" > #include "mysql/plugin.h" > #include "ha_perfschema.h" > #include "pfs_engine_table.h" > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 1

[Maria-developers] Buildbot trees for spider and mroonga
by Alexander Barkov 10 Feb '14

10 Feb '14

Hi Kentoku, Currently you use your own trees for Mroonga and Spider development, e.g. bzr+ssh://bazaar.launchpad.net/~mroonga/maria/mroonga/ Would you mind to move development into trees under ~maria-captains location, for example: bzr+ssh://bazaar.launchpad.net/~maria-captains/maria/10.0-mroonga/ bzr+ssh://bazaar.launchpad.net/~maria-captains/maria/10.0-spider/ This will give an great advantage to have every revision compiled and tested on a wide variety of operating systems (this is done automatically by MariaDB Build Bot), and also will help us to merge your updates into the main 10.0 tree easier. Note, development in these trees should be done "incrementally". Things like "bzr push --overwrite" are not desirable, to avoid problems with BiildBot and with merges. Hope this is not a big problem. Thanks.

3 4

[Maria-developers] Updating OQGRAPH tables
by Ian Gilfillan 08 Feb '14

08 Feb '14

Hi I have been struggling to get OQGRAPH working with MariaDB 10.0.7. The system has been hanging and crashing frequently. I will post as bugs if I can recreate them, but this question is simply, how can I update the data? On a new install of MariaDB 10.0.7 and OQGRAPH - I create the sample tables at https://mariadb.com/kb/en/oqgraph-examples/#creating-a-table-with-weight - I then update the oq2_backing table. The changes reflect on the oq2_backing table, not the oq2_graph table: UPDATE oq2_backing SET weight=4 WHERE origid=2 AND destid=6; SELECT * FROM oq2_backing; +--------+--------+--------+ | origid | destid | weight | +--------+--------+--------+ | 1 | 2 | 1 | | 2 | 3 | 1 | | 2 | 6 | 4 | | 3 | 4 | 3 | | 4 | 5 | 1 | | 5 | 6 | 2 | +--------+--------+--------+ SELECT * FROM oq2_graph; +-------+--------+--------+--------+------+--------+ | latch | origid | destid | weight | seq | linkid | +-------+--------+--------+--------+------+--------+ | NULL | 1 | 2 | 1 | NULL | NULL | | NULL | 2 | 3 | 1 | NULL | NULL | | NULL | 2 | 6 | 10 | NULL | NULL | | NULL | 3 | 4 | 3 | NULL | NULL | | NULL | 4 | 5 | 1 | NULL | NULL | | NULL | 5 | 6 | 2 | NULL | NULL | +-------+--------+--------+--------+------+--------+ How can I make changes that reflect on the table? thanks, ian

2 2

[Maria-developers] GCC native thread local storage (Was: [Maria-discuss] xtradb in 10.0)
by Kristian Nielsen 07 Feb '14

07 Feb '14

Laurynas Biveinis <laurynas.biveinis(a)gmail.com> writes: > We have another platform-specific addition: thread-local storage > implemented by __thread GCC keyword, which is GNU specific. This is Hm, this is interesting, I was not aware of the __thread feature. This looks to be much more efficient than pthread_getspecific(), which is one of the top functions in the profiles for sysbench readonly: static __thread long tcount = 0; long bump(long del) { return (tcount += del); } 0000000000000000 <bump>: 0: 48 89 f8 mov %rdi,%rax 3: 64 48 03 04 25 00 00 add %fs:0x0,%rax a: 00 00 c: 64 48 89 04 25 00 00 mov %rax,%fs:0x0 13: 00 00 15: c3 retq It is just a single instruction using %fs: addressing to access the thread_local storage. Apparently the linker resolves the %fs: offset in the resulting binary: 0000000000400580 <bump>: 400580: 48 89 f8 mov %rdi,%rax 400583: 64 48 03 04 25 e0 ff add %fs:0xffffffffffffffe0,%rax 40058a: ff ff 40058c: 64 48 89 04 25 e0 ff mov %rax,%fs:0xffffffffffffffe0 400593: ff ff 400595: c3 retq 00000000004005a0 <bump2>: 4005a0: 48 89 f8 mov %rdi,%rax 4005a3: 64 48 03 04 25 f0 ff add %fs:0xfffffffffffffff0,%rax 4005aa: ff ff 4005ac: 64 48 89 04 25 f0 ff mov %rax,%fs:0xfffffffffffffff0 4005b3: ff ff 4005b5: c3 retq So that could be very promising for an easy way to tweak out a little more performance. Something to look into at some point. - Kristian.

1 0

[Maria-developers] MariaDB 10.0.8 release prep
by Daniel Bartholomew 06 Feb '14

06 Feb '14

I've started preparing for the MariaDB 10.0.8 release. Draft changelog and release notes are here: - https://mariadb.com/kb/en/mariadb-1008-changelog/ - https://mariadb.com/kb/en/mariadb-1008-release-notes/ Please let me know ASAP about things that should be mentioned in the release notes (or add them yourself). Thanks! -- Daniel Bartholomew MariaDB

1 0

Re: [Maria-developers] [Commits] Rev 3984: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. in file:///home/hf/wmar/10-hf/
by Jan Lindström 06 Feb '14

06 Feb '14

Hi, Change: Another change is that it uses the index name for the internal dictionary. Not ok. Firstly, that change should affect many test cases using foreign keys. Secondly, that would effect applications using foreign keys. I could only imagine how many and what kind of applications there are to create/drop foreign keys that are currently created with InnoDB internal foreign key names. Finally, this fix is 'correct' only for new tables, not existing tables containing foreign keys. This change would be incompatibility change to default behavior. > At file:///home/hf/wmar/10-hf/ > > ------------------------------------------------------------ > revno: 3984 > revision-id: holyfoot(a)askmonty.org-20140205184909-9nmsj1mzwo6cka0m > parent: sergii(a)pisem.net-20140205171851-0vax8lnwtbousucu > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: 10-hf > timestamp: Wed 2014-02-05 22:49:09 +0400 > message: > MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. > Patches for server and the Innodb engine. > Server is fixed so it does nothing if no indexes left to alter. > Innodb parser is fixed so it looks for the IF [NOT] EXISTS option in a string. > Another change is that it uses the index name for the internal dictionary. > Prior to that it only used the CONSTRAINT name for it. > > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- -- Jan Lindström Principal Engineer MariaDB | MaxScale | skype: jan_p_lindstrom www.skysql.com <http://www.skysql.com/> Twitter <http://twitter.com/skysql> Blog <http://www.skysql.com/blog/> Facebook <http://www.facebook.com/skysql> LinkedIn <http://www.linkedin.com/company/1214250> Google+ <https://plus.google.com/117544963211695643458/posts>

2 3

Re: [Maria-developers] MariaDB
by Kristian Nielsen 04 Feb '14

04 Feb '14

Otto Kekäläinen <otto(a)seravo.fi> writes: > 2013-10-01 Otto Kekäläinen <otto(a)fsfe.org>: >> 2013/10/1 Ondřej Surý <ondrej(a)sury.org>: >>> - it would be better to repack the tarball and kill the upstream debian/ >>> directory to not mess with our packaging >> >> I hope to merge my work upstream and that is easier if my changes are >> a made on top of current upstream. I think most of the changes should >> be useful for upstream too. Maybe you can participate in the process >> to create patches and test that they work for upstream OK? > there much easier. Although I will be needing help from somebody to > make autobuild.sh and standard Debian builders work nicely on the same > code base. Wouldn't it be better to discard the existing debian/ stuff in the upstream sources, and work from the native Debian packaging as the base? The existing stuff has _so_ much legacy and crap, and little of value. It has origins in some ancient copy of native Debian packages, then OurDelta hacked it for their build infrastructure (the autobuild.sh stuff), then MariaDB for our build infrastructure. It has desperately needed a cleanup for so long. Since this cleanup has now been done in native Debian packaging, which also makes unnecessary some of the hacks to work with native Debian packages, it seems better to just use Otto's work as the base going forwards. And in any case, the old reason for having debian packaging in-tree no longer applies. Now, we need to make sure before each release of MariaDB that it will play nicely with the upstream Debian packaging, and for this it seems most useful to pull in the packaging from the Debian packaging git repo? Well, in the end it is up to you. I suppose in any case there will be a wish to provide 3rd-party MariaDB .debs, eg. to provide backports to older distros of new versions. It just seems more natural to focus primarily on having good native packages and then accommodating the 3rd-party stuff, rather than the other way around? - Kristian.

3 4

[Maria-developers] MDEV-5273
by Alexey Botchkov 04 Feb '14

04 Feb '14

Hi, Serg, all. I'm not sure how about fixing this one: https://mariadb.atlassian.net/browse/MDEV-5273 So would like your opinion. The thing is that the SHOW commands with old-fasioned implementations (those that aren't mapped to the SELECT FROM information_schema.something) return stmt->field_count == 0 after the mysql_prepare_statement. The fix i see involves some boring coding. Is it worth to get into it right now? Best regards. HF

2 1

Re: [Maria-developers] [Commits] Rev 3966: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. in file:///home/hf/wmar/10-hf/
by Jan Lindström 04 Feb '14

04 Feb '14

Hi, In my opinion the test case is not complete, you are missing e.g. ALTER TABLE t2 ADD FOREIGN KEY IF NOT EXISTS (id) REFERENCES t1(id); -- should fail on warning ALTER TABLE t2 ADD FOREIGN KEY IF NOT EXISTS (id) REFERENCES t1(id); ALTER TABLE t2 ADD FOREIGN KEY IF NOT EXISTS a(id REFERENCES t1(id); -- should fail, there is already foreign key for id, yes it name is not b or a but anyway ALTER TABLE t2 ADD FOREIGN KEY IF NOT EXISTS b(id) REFERENCES t1(id); R: > At file:///home/hf/wmar/10-hf/ > > ------------------------------------------------------------ > revno: 3966 > revision-id: holyfoot(a)askmonty.org-20140201114304-7bi0ug2yg3eyyhlr > parent: psergey(a)askmonty.org-20140121100700-9g8hl8vx8nmk1e2w > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: 10-hf > timestamp: Sat 2014-02-01 15:43:04 +0400 > message: > MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. > Patches for server and the Innodb engine. > Server is fixed so it does nothing if no indexes left to alter. > Innodb parser is fixed so it looks for the IF [NOT] EXISTS option in a string. > Another change is that it uses the index name for the internal dictionary. > Prior to that it only used the CONSTRAINT name for it. > > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- -- Jan Lindström Principal Engineer MariaDB | MaxScale | skype: jan_p_lindstrom www.skysql.com <http://www.skysql.com/> Twitter <http://twitter.com/skysql> Blog <http://www.skysql.com/blog/> Facebook <http://www.facebook.com/skysql> LinkedIn <http://www.linkedin.com/company/1214250> Google+ <https://plus.google.com/117544963211695643458/posts>

2 3

[Maria-developers] Extra copying in debian/rules causes troubles
by Elena Stepanova 04 Feb '14

04 Feb '14

Hi all. There is a fragment in MariaDB debian/dist/*/rules files: ... ifeq ($(findstring nocheck,$(DEB_BUILD_OPTIONS)),) # Don't know why the following is necessary... cp unittest/unit.pl $(builddir)/unittest/ cp -r mysql-test/* $(builddir)/mysql-test/ cp -r sql/share/* $(builddir)/sql/share/ cp -r scripts/*sql $(builddir)/scripts/ if [ ! -f testsuite-stamp ] ; then \ ... Recently it started causing a problem. MTR assumes that the tests are run either in a proper source build (be it in-source or out-of-source), or in a binary build. With the extra-copying above, particularly due to copying of mysql-test folder, the builddir by the moment of running tests is in the "neither fish nor fowl" state. So if one runs dpkg-buildpackage with the tests enabled, it fails when it comes to the MTR stage. We had this problem reported at least 3 times over the last 24 hours, so it's not hypothetical. It's currently filed as https://mariadb.atlassian.net/browse/MDEV-5591. I tried to remove these 4 'cp' lines and the build seemed to work all right; but there might also be consequences that I fail to predict, so I would like to have the 2nd (3rd, 4th, ... Nth) opinion. Does anyone have any idea what might go wrong without these 4 lines? Also, *Kristian*, These lines are coming from the initial draft of the rules. I understand from the comment that there is no reason to ask *why* the lines were necessary, but I'm wondering if you remember why you felt they *were* necessary (even if didn't know why). Were you getting some errors without them? Or were they copied from some previous version of the file? I realize it was long time ago so you probably won't remember, but I thought it was worth checking anyway. Regards, Elena

3 4

[Maria-developers] MariaDB 5.5.35
by ImperialNetwork 04 Feb '14

04 Feb '14

Hi, I started to notice this on my error log since i upgraded from 5.5.34 to 5.5.35: 140203 5:26:25 InnoDB: Failed to set O_DIRECT on file /dev/shm/#sql7e8f6_1a94bc_10.ibd: CREATE: Invalid argument, continuing anyway 140203 5:26:25 InnoDB: O_DIRECT is known to result in 'Invalid argument' on Linux on tmpfs, see MySQL Bug#26662 I never seen this error/warning until 5.5.35. Should this be normal ? Thank you in advance. Alex

3 3

[Maria-developers] MDEV-5450 Assertion ... mysql_type_to_time_type(cached_field_type) == ltime.time_type' fails ...
by Alexander Barkov 03 Feb '14

03 Feb '14

Hi Sergei, Please review a patch for mdev-5450. Thanks.

2 3

[Maria-developers] MariaDB build dependencies
by Otto Kekäläinen 03 Feb '14

03 Feb '14

Hello, The original MariaDB debian/control in bzr/mariadb-5.5 lists many more dependencies than what are likely to be needed: Build-Depends: libtool (>= 1.4.2-7), procps | hurd, debhelper, file (>= 3.28), libncurses5-dev (>= 5.0-6), perl (>= 5.6.0), libwrap0-dev (>= 7.6-8.3), zlib1g-dev (>= 1:1.1.3-5), ${LIBREADLINE_DEV}, libevent-dev, libssl-dev, libpam0g-dev, psmisc, po-debconf, chrpath, automake1.9, doxygen, texlive-latex-base, ghostscript | gs-gpl, dpatch, gawk, bison, lsb-release, hardening-wrapper, ${CMAKE_DEP}libaio-dev The source builds error free with just: libaio-dev libncurses5-dev perl libwrap0-dev zlib1g-dev libreadline-gplv2-dev po-debconf psmisc chrpath gawk bison lsb-release hardening-wrapper cmake libssl-dev libboost1.48-dev libpam0g-dev Can anybody tell me how in particular these are supposed to affect the build process? - libevent-dev - doxygen, texlive-latex-base, ghostscript | gs-gpl - gawk Debian MySQL team has a page https://wiki.debian.org/Teams/MySQL/BuildDependencies but obiviously MariaDB is different in these aspects, for example MariaDB needs libpam0g-dev for auth_pam.so which does not exist in MySQL. If anybody can explain the above that would be great, thanks!

3 3

Re: [Maria-developers] Rev 3966: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used
by Sergei Golubchik 01 Feb '14

01 Feb '14

Hi, Holyfoot! On Feb 01, holyfoot(a)askmonty.org wrote: > revno: 3966 > revision-id: holyfoot(a)askmonty.org-20140201114304-7bi0ug2yg3eyyhlr > parent: psergey(a)askmonty.org-20140121100700-9g8hl8vx8nmk1e2w > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: 10-hf > timestamp: Sat 2014-02-01 15:43:04 +0400 > message: > MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. > Patches for server and the Innodb engine. > Server is fixed so it does nothing if no indexes left to alter. > Innodb parser is fixed so it looks for the IF [NOT] EXISTS option in a string. > Another change is that it uses the index name for the internal dictionary. > Prior to that it only used the CONSTRAINT name for it. ok to push Regards, Sergei

1 0

Re: [Maria-developers] Rev 3886: MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used
by Sergei Golubchik 31 Jan '14

31 Jan '14

Hi, Holyfoot! On Jan 31, holyfoot(a)askmonty.org wrote: > At file:///home/hf/wmar/mdev-4439/ > > ------------------------------------------------------------ > revno: 3886 > revision-id: holyfoot(a)askmonty.org-20140131134044-ej3ftpf240xbn0lc > parent: knielsen(a)knielsen-hq.org-20131107065240-gxxg4ilcs8o2v0q2 > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-4439 > timestamp: Fri 2014-01-31 17:40:44 +0400 > message: > MDEV-4439 ALTER TABLE .. [ADD|DROP] FOREIGN KEY IF [NOT] EXISTS does not work if constraint name is not used. > Patches for server and the Innodb engine. > Server is fixed so it does nothing if no indexes left to alter. > Innodb parser is fixed so it looks for the IF [NOT] EXISTS option, takes into account > the drop->if_not_exists parameter. > Another change is that it uses the index name for the internal dictionary. > Prior to that it only used the CONSTRAINT name for it. That looks pretty much ok, but please add tests that use generated FK names. For example, it doesn't look like you handle the case of ADD FOREIGN KEY IF NOT EXISTS existing_generated_name (...) Regards, Sergei

1 0

[Maria-developers] buildbot for non ~maria-captains branches on launchpad
by Alexander Barkov 31 Jan '14

31 Jan '14

Hello Daniel, Would it be possible to have buildbot watch branches which are on Launchpad, but which are outside of the /~maria-captains/ directory? For example: bzr+ssh://bazaar.launchpad.net/~mroonga/maria/mroonga/ ? Thanks.

3 5

Re: [Maria-developers] Rev 3965: MDEV-5403 - Reduce usage of LOCK_open: tc_count
by Sergei Golubchik 31 Jan '14

31 Jan '14

Hi, Sergey! Please, see below. On Jan 30, Sergey Vojtovich wrote: > revno: 3965 > revision-id: svoj(a)mariadb.org-20140130123642-wsysj31e1wwlqz0o > parent: psergey(a)askmonty.org-20140120123657-g1z4g11xmsdiw2dc > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Thu 2014-01-30 16:36:42 +0400 > message: > MDEV-5403 - Reduce usage of LOCK_open: tc_count > > Lock-free tc_count. > === modified file 'sql/table_cache.cc' > --- a/sql/table_cache.cc 2013-12-12 17:49:14 +0000 > +++ b/sql/table_cache.cc 2014-01-30 12:36:42 +0000 > @@ -173,7 +175,9 @@ void tc_purge(void) > { > share->tdc.all_tables.remove(table); > purge_tables.push_front(table); > - tc_count--; > + my_atomic_rwlock_wrlock(&LOCK_tdc_atomics); > + my_atomic_add32(&tc_count, -1); > + my_atomic_rwlock_wrunlock(&LOCK_tdc_atomics); Okay, so in this new code tc_count is always equal or greater than the actual number of tables in the cache, right? (because you first remove the table from the cache, then decrement the counter) > } > } > tdc_it.deinit(); > @@ -245,47 +249,52 @@ static void check_unused(THD *thd) > > void tc_add_table(THD *thd, TABLE *table) > { > + bool need_purge; > DBUG_ASSERT(table->in_use == thd); > mysql_mutex_lock(&LOCK_open); > table->s->tdc.all_tables.push_front(table); > + mysql_mutex_unlock(&LOCK_open); > + > /* If we have too many TABLE instances around, try to get rid of them */ > - if (tc_count == tc_size) > + my_atomic_rwlock_wrlock(&LOCK_tdc_atomics); > + need_purge= my_atomic_add32(&tc_count, 1) >= (int32) tc_size; Hmm, but here you increment after adding a table. I'd suggest to keep tc_count consistently either always no smaller than the number of tables in the cache (that is, decrement after removing, increment before adding), or always no larger than that (derement before removing, increment after adding). > + my_atomic_rwlock_wrunlock(&LOCK_tdc_atomics); > + > + if (need_purge) > { > + TABLE *purge_table= 0; > + TABLE_SHARE *share; > TDC_iterator tdc_it; > - mysql_mutex_unlock(&LOCK_open); > > tdc_it.init(); > mysql_mutex_lock(&LOCK_open); > - if (tc_count == tc_size) > - { > - TABLE *purge_table= 0; > - TABLE_SHARE *share; > while ((share= tdc_it.next())) > { > TABLE_SHARE::TABLE_list::Iterator it(share->tdc.free_tables); > TABLE *entry; > while ((entry= it++)) > if (!purge_table || entry->tc_time < purge_table->tc_time) > purge_table= entry; > } > + tdc_it.deinit(); > + > if (purge_table) > { > - tdc_it.deinit(); > purge_table->s->tdc.free_tables.remove(purge_table); > purge_table->s->tdc.all_tables.remove(purge_table); > mysql_rwlock_rdlock(&LOCK_flush); > mysql_mutex_unlock(&LOCK_open); > intern_close_table(purge_table); > mysql_rwlock_unlock(&LOCK_flush); > + > + my_atomic_rwlock_wrlock(&LOCK_tdc_atomics); > + my_atomic_add32(&tc_count, -1); > + my_atomic_rwlock_wrunlock(&LOCK_tdc_atomics); > check_unused(thd); > - return; > } > - } > - tdc_it.deinit(); > - } > - /* Nothing to evict, increment tc_count. */ > - tc_count++; > + else > mysql_mutex_unlock(&LOCK_open); > + } > } > > > @@ -357,25 +366,35 @@ bool tc_release_table(TABLE *table) > DBUG_ASSERT(table->in_use); > DBUG_ASSERT(table->file); > > + if (table->needs_reopen() || tc_records() > tc_size) > + { > + mysql_mutex_lock(&LOCK_open); > + table->in_use= 0; > + goto purge; > + } Why did you move this up? > table->tc_time= my_interval_timer(); > > mysql_mutex_lock(&LOCK_open); > table->in_use= 0; > - if (table->s->has_old_version() || table->needs_reopen() || tc_count > tc_size) > - { > - tc_count--; > + if (table->s->has_old_version()) > + goto purge; > + /* Add table to the list of unused TABLE objects for this share. */ > + table->s->tdc.free_tables.push_front(table); > + mysql_mutex_unlock(&LOCK_open); > + check_unused(thd); > + return false; > + > +purge: > + my_atomic_rwlock_wrlock(&LOCK_tdc_atomics); > + my_atomic_add32(&tc_count, -1); > + my_atomic_rwlock_wrunlock(&LOCK_tdc_atomics); > table->s->tdc.all_tables.remove(table); and now you decrement before removal > mysql_rwlock_rdlock(&LOCK_flush); > mysql_mutex_unlock(&LOCK_open); > intern_close_table(table); > mysql_rwlock_unlock(&LOCK_flush); > return true; > - } > - /* Add table to the list of unused TABLE objects for this share. */ > - table->s->tdc.free_tables.push_front(table); > - mysql_mutex_unlock(&LOCK_open); > - check_unused(thd); > - return false; > } > > Regards, Sergei

2 1

[Maria-developers] FreeBSD compilation problems and a fix
by Alexander Barkov 31 Jan '14

31 Jan '14

Hi guys, I just tried to compile 10.0 on FreeBSD-9.1 RELEASE and noticed two problems: 1. It printed this warning for every source file: /usr/include/sys/timeb.h:42:2: warning: #warning "this file includes <sys/timeb.h> which is deprecated" This diff fixes the problem: -#ifdef HAVE_SYS_TIMEB_H +#if defined(HAVE_SYS_TIMEB_H) && !defined(__FreeBSD__) 2. It failed to compile because of pcre (both libraries and includes) installed in the system. Compiler used the *system* header pcre.h together with the *bundled* library libpcre.a. I had a similar complaint from the MacPorts maintainers. This diff fixes the problem: # Common defines and includes +SET(CMAKE_INCLUDE_DIRECTORIES_PROJECT_BEFORE ON) ADD_DEFINITIONS(-DHAVE_CONFIG_H) INCLUDE_DIRECTORIES(${CMAKE_CURRENT_BINARY_DIR}/include Does this look OK? If so, which version should I push it in? Thanks.

2 3

Re: [Maria-developers] Rev 3966: MDEV-5492 - Reduce usage of LOCK_open: TABLE::in_use
by Sergei Golubchik 30 Jan '14

30 Jan '14

Hi, Sergey! On Jan 29, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 3966 > revision-id: svoj(a)mariadb.org-20140129083115-jwye7zfyncrq9crs > parent: svoj(a)mariadb.org-20140124075326-d7twer07e0bu42b5 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Wed 2014-01-29 12:31:15 +0400 > message: > MDEV-5492 - Reduce usage of LOCK_open: TABLE::in_use > > Move TABLE::in_use out of LOCK_open. > > This is done with assumtion that foreign threads accessing TABLE::in_use > will only need consistent value _after_ marking table for flush and purging > unused table instances. In this case TABLE::in_use will always point to a > valid thread object. I believe I was able to understand what you were doing here :) Seems ok. The assumption above looks a bit risky without any way to enforce it. Perhaps you could make in_use private (renaming to, say, m_in_use) and add an inline getter method TABLE::in_use() that in debug builds will assert that your assumption holds? Regards, Sergei

2 2

[Maria-developers] MDEV-4309, second patch: review
by Sergei Petrunia 29 Jan '14

29 Jan '14

Hello, This is a review for MDEV-4309, second patch: https://mariadb.atlassian.net/secure/attachment/21510/201303271828_sanja_co… === The name "memcmp_func" is confusing, because the function has nothing to do with memcmp. Did you mean memcpy actually? The function should be renamed to something like "memcpy_field_value". memcmp_func() still makes one virtual call. === Consider a scenario: - Item_field::setup_cpy_optimizer() is called. - It calls memcmp_possible(), which returns FALSE, which means field_conv() will be called for every row. - field_conv() will still call memcpy_field_value(), even if we know that it will return false. Why not add a field_conv_incompatible() and make field_conv look like this: find_conv() { if (memcmp_possible()) { ... } return field_conv_incompatible(); } === The name "cpy_optimizer" is very cryptic. Is "Fast_field_copier" better? === class Item_field has this member: Field *cpy_optimizer_setup; I don't see how it is useful without its corresponding 'cpy_optimizer' data. cpy_optimizer is only present inside ORDER structure which has both: cpy_optimizer cpy_optimizer_func; Field *cpy_optimizer_setup; If ORDER has both members, why have the Item_field::cpy_optimizer_setup ? === Let's discuss this on IRC. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] single thread performance (was: Re: Need to check if the slowdown is still there)
by Sergei Petrunia 29 Jan '14

29 Jan '14

Hi Axel, On Tue, Jan 28, 2014 at 04:27:10PM +0100, Axel Schwenke wrote: > Hi, > > I have now re-run a benchmark to test single thread performance. This is the > continuation of MDEV-4309. > Thanks for the data. > ... > The numbers demonstrate quite clearly the general observation that with each > new major version of MariaDB/MySQL the code path becomes longer and the > performance suffers. But there is also good news: sometimes during the > maturing of a release the performance may increase again. I.e. I have seen > significant changes from MySQL-5.6.13 to 5.6.14. I agree with the observations. I would even say that MySQL was getting worse in 5.6.11 - 5.6.13 versions, and then fixe something in 5.6.14. > Also from MariaDB-5.5.30 to > 5.5.31 (which was when MDEV-4309 was implemented). Unfortunately between > MariaDB-5.5.33 and 5.5.34 most of that was lost again :( The first step in not letting that happen is to have the benchmark data so that we know if there are any problems. The patch for MDEV-4309 part#2 is not yet ready. We will get back to you when it can be used for testing. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] The "Monty Program AB" vendor check (rpm)
by Oden Eriksson 28 Jan '14

28 Jan '14

Hello, I got assigned to look at the rpm packaging and fixed some stuff there, but got stuck at the "Monty Program AB" vendor check in support-files/rpm/server- prein.sh when I wanted to replace the fedora packages with in this case mariadb galera packages. Is this check absolutely nessesary? This prevents you from an easy switch from the fedora mariadb packages to the ones provided by mariadb using yum and a yum repository as provided at http://yum.mariadb.org/. Basically this check prevents me from doing any serious work with the rpm packages because you manually have to, by force deinstall any conflicting packages and then install the packages provided by us. Cheers.

3 3

Re: [Maria-developers] Review request for a fix for MDEV-5506
by Sergei Golubchik 28 Jan '14

28 Jan '14

Hi, Alexander! Few questions, see below. > === modified file 'mysql-test/t/timezone2.test' > --- mysql-test/t/timezone2.test 2013-08-08 08:58:28 +0000 > +++ mysql-test/t/timezone2.test 2014-01-23 10:34:46 +0000 > @@ -298,5 +298,11 @@ SELECT CONVERT_TZ(TIME('00:00:00'),'+00: > SELECT CONVERT_TZ(TIME('2010-01-01 00:00:00'),'+00:00','+7:5'); > > --echo # > +--echo # MDEV-5506 safe_mutex: Trying to lock unitialized mutex at safemalloc.c on server shutdown after SELECT with CONVERT_TZ > +--echo # > +SELECT CONVERT_TZ('2001-10-08 00:00:00', MAKE_SET(0,'+01:00'), '+00:00' ); hmm, the bug description was "at shutdown". I don't see a shutdown in your test case. I suppose, you assume that the server will be eventually shut down and that'll do. But perhaps it needs to be shut down immediately, and if mtr will do a lot of work in this server the test case becomes invalid - it won't crash anymore? > === modified file 'sql/item_strfunc.cc' > --- sql/item_strfunc.cc 2013-09-25 12:30:13 +0000 > +++ sql/item_strfunc.cc 2014-01-23 10:17:57 +0000 > @@ -43,7 +43,7 @@ C_MODE_END > /** > @todo Remove this. It is not safe to use a shared String object. > */ I guess, you've fixed that and can remove the comment. > -String my_empty_string("",default_charset_info); > +String_const my_empty_string("", default_charset_info); > > === modified file 'sql/sql_string.h' > --- sql/sql_string.h 2012-11-09 08:11:20 +0000 > +++ sql/sql_string.h 2014-01-23 10:26:13 +0000 > @@ -56,25 +56,52 @@ uint convert_to_printable(char *to, size > > class String > { > + typedef enum > + { > + STRING_FLAG_NONE= 0, > + STRING_FLAG_ALLOCED= 1, > + STRING_FLAG_READ_ONLY= 2, > + STRING_FLAG_NULL_TERMINATED= 4 > + } flag_t; > char *Ptr; > uint32 str_length,Alloced_length, extra_alloc; > - bool alloced; > + flag_t flags; > CHARSET_INFO *str_charset; Okay, I understand what you did. But I don't understand why. What was the problem? Why there was a crash? Regards, Sergei

2 4

[Maria-developers] MariaDB 5.5.35 Release Prep
by Daniel Bartholomew 28 Jan '14

28 Jan '14

All, I've begun the prep work for the MariaDB 5.5.35 release. The draft changelog and release notes are here: - https://mariadb.com/kb/en/mariadb-5535-changelog/ - https://mariadb.com/kb/en/mariadb-5535-release-notes/ Please let me know ASAP if there's anything that needs to be mentioned/highlighted/removed/etc... The release is still building in buildbot. If all goes well, the plan is to begin uploading the files to the mirrors later today and then to activate the release as soon as most mirrors have picked up the files. Thanks. -- Daniel Bartholomew MariaDB

1 0

[Maria-developers] 5.5.35 Release ?
by ImperialNetwork 27 Jan '14

27 Jan '14

Hi, I was wondering if MariaDB 5.5.35 is going to be released today as stated on jira page. I plan some maintenance and i will do it as soon as 5.5.35 will be released. Thank you in advance Alexandru

2 1

Re: [Maria-developers] Rev 4009: MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES
by Sergei Golubchik 27 Jan '14

27 Jan '14

Hi, Sergey! Ok to push. A couple of comments below: On Jan 27, Sergey Vojtovich wrote: > revno: 4009 > revision-id: svoj(a)mariadb.org-20140127090430-g63lt751yxw9ddud > parent: sergii(a)pisem.net-20131217162654-dw2zlm3td1p12bxl > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5345 > timestamp: Mon 2014-01-27 13:04:30 +0400 > message: > MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > INSTALL PLUGIN > > === modified file 'sql/sql_plugin.cc' > --- a/sql/sql_plugin.cc 2013-12-12 17:14:08 +0000 > +++ b/sql/sql_plugin.cc 2014-01-27 09:04:30 +0000 > @@ -1196,6 +1190,9 @@ static void plugin_deinitialize(struct s > if (ref_check && plugin->ref_count) > sql_print_error("Plugin '%s' has ref_count=%d after deinitialization.", > plugin->name.str, plugin->ref_count); > + > + mysql_del_sys_var_chain(plugin->system_vars); > + restore_pluginvar_names(plugin->system_vars); Can mysql_del_sys_var_chain() be called from inside restore_pluginvar_names() ? They seem always to be called together. > @@ -1342,7 +1335,8 @@ void plugin_unlock_list(THD *thd, plugin > } > > > -static int plugin_initialize(struct st_plugin_int *plugin) > +static int plugin_initialize(MEM_ROOT *tmp_root, struct st_plugin_int *plugin, > + int *argc, char **argv, bool options_only) > { I thought you'll rename a function :) But that's just fine too, whatever you prefer. Regards, Sergei

1 0

Re: [Maria-developers] MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES
by Sergei Golubchik 27 Jan '14

27 Jan '14

Hi, Sergey! Looks ok, see a couple of question (and minor style-related comments) below. On Dec 27, Sergey Vojtovich wrote: > At lp:maria/5.5 > > ------------------------------------------------------------ > revno: 4009 > revision-id: svoj(a)mariadb.org-20131227101419-ahpdahcundclr6gv > parent: sergii(a)pisem.net-20131217162654-dw2zlm3td1p12bxl > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 5.5-mdev5345 > timestamp: Fri 2013-12-27 14:14:19 +0400 > message: > MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > INSTALL PLUGIN > > There was mixed lock order between LOCK_plugin, LOCK_global_system_variables > and LOCK_system_variables_hash. This patch ensures that write-lock on > LOCK_system_variables_hash doesn't intersect with LOCK_plugin. > > Fixed by moving initialization/deinitialization of plugin options from > plugin_add()/plugin_del() to plugin_initialize()/plugin_deinitalize(). > So that plugin options are handled without protection of LOCK_plugin. > === added file 'mysql-test/r/plugin_vars.result' > --- a/mysql-test/r/plugin_vars.result 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/r/plugin_vars.result 2013-12-27 10:14:19 +0000 > @@ -0,0 +1,22 @@ > +# > +# MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > +# INSTALL PLUGIN > +# > +CREATE PROCEDURE p_install(x INT) > +BEGIN > +DECLARE CONTINUE HANDLER FOR 1126 BEGIN END; > +WHILE x DO > +SET x= x - 1; > +INSTALL PLUGIN no_such_plugin SONAME 'no_such_object'; > +END WHILE; > +END| > +CREATE PROCEDURE p_show_vars(x INT) > +WHILE x DO > +SET x= x - 1; > +SHOW VARIABLES; > +END WHILE| > +CALL p_install(100);; > +CALL p_show_vars(100);; Note two semicolons at the end. The mysqltest syntax is either builtin_command arguments; or --builtin_command arguments I mean, it either ends with a semicolon or starts with dash-dash. Not a big deal, of course :) > +USE test; > +DROP PROCEDURE p_install; > +DROP PROCEDURE p_show_vars; > > === added file 'mysql-test/t/plugin_vars.test' > --- a/mysql-test/t/plugin_vars.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/t/plugin_vars.test 2013-12-27 10:14:19 +0000 > @@ -0,0 +1,56 @@ > +--echo # > +--echo # MDEV-5345 - Deadlock between mysql_change_user(), SHOW VARIABLES and > +--echo # INSTALL PLUGIN > +--echo # > + > +# Prepare test > +delimiter |; > +CREATE PROCEDURE p_install(x INT) > +BEGIN > + DECLARE CONTINUE HANDLER FOR 1126 BEGIN END; > + WHILE x DO > + SET x= x - 1; > + INSTALL PLUGIN no_such_plugin SONAME 'no_such_object'; > + END WHILE; > +END| > + > +CREATE PROCEDURE p_show_vars(x INT) > +WHILE x DO > + SET x= x - 1; > + SHOW VARIABLES; > +END WHILE| > +delimiter ;| > + > +connect(con1, localhost, root,,); > +connect(con2, localhost, root,,); > + > +# Start test > +connection con1; > +--send CALL p_install(100); > + > +connection con2; > +--send CALL p_show_vars(100); Why did you prefer this test over a deterministic one with debug sync points? > +connection default; > + > +disable_result_log; > +let $i= 100; > +while ($i) > +{ > + change_user; > + dec $i; > +} > + > +# Cleanup > +connection con1; > +reap; > +connection con2; > +reap; > +connection default; > +enable_result_log; > + > +disconnect con1; > +disconnect con2; > +USE test; > +DROP PROCEDURE p_install; > +DROP PROCEDURE p_show_vars; > > === modified file 'sql/sql_plugin.cc' > --- a/sql/sql_plugin.cc 2013-12-12 17:14:08 +0000 > +++ b/sql/sql_plugin.cc 2013-12-27 10:14:19 +0000 > @@ -201,7 +202,7 @@ static bool initialized= 0; > write-lock on LOCK_system_variables_hash is required before modifying > the following variables/structures > */ > -static MEM_ROOT plugin_mem_root; > +static MEM_ROOT plugin_vars_mem_root; ok, so you couldn't consistently use one lock for plugin_mem_root, and had to create a second memroot. I see. another option would be to use one memroot and a dedicated lock for it. but I don't think it matters much what solution we use here :) > static uint global_variables_dynamic_size= 0; > static HASH bookmark_hash; > > @@ -1342,7 +1337,8 @@ void plugin_unlock_list(THD *thd, plugin > } > > > -static int plugin_initialize(struct st_plugin_int *plugin) > +static int plugin_initialize(MEM_ROOT *tmp_root, struct st_plugin_int *plugin, > + int *argc, char **argv, bool initialize) this looks pretty weird. plugin_initialize() function that doesn't initialize if its initialize argument is false? perhaps it's better to rename the function then? Or create another one that tests plugin options and invokes plugin_initialize() if necessary? > { > int ret= 1; > DBUG_ENTER("plugin_initialize"); > @@ -1413,6 +1421,14 @@ static int plugin_initialize(struct st_p > ret= 0; > > err: > + if (ret) > + { > + mysql_rwlock_wrlock(&LOCK_system_variables_hash); > + mysql_del_sys_var_chain(plugin->system_vars); > + mysql_rwlock_unlock(&LOCK_system_variables_hash); > + restore_pluginvar_names(plugin->system_vars); may be, you'd move these four lines in a separate function? like, cleanup_plugin_sysvars() ? > + } > + > mysql_mutex_lock(&LOCK_plugin); > plugin->state= state; > > @@ -1646,9 +1654,10 @@ int plugin_init(int *argc, char **argv, > for (i= 0; i < plugin_array.elements; i++) > { > plugin_ptr= *dynamic_element(&plugin_array, i, struct st_plugin_int **); > - if (plugin_ptr->state == PLUGIN_IS_UNINITIALIZED) > + if (plugin_ptr->plugin_dl && plugin_ptr->state == PLUGIN_IS_UNINITIALIZED) Why? > { > - if (plugin_initialize(plugin_ptr)) > + if (plugin_initialize(&tmp_root, plugin_ptr, argc, argv, > + !(flags & PLUGIN_INIT_SKIP_INITIALIZATION))) > { > plugin_ptr->state= PLUGIN_IS_DYING; > *(reap++)= plugin_ptr; Regards, Sergei

2 4

Re: [Maria-developers] Please review MDEV-5458 RQG hits 'sql/tztime.cc:799: my_time_t sec_since_epoch(int, int, int, int, int, int): Assertion `mon > 0 && mon < 13' failed.'
by Sergei Golubchik 27 Jan '14

27 Jan '14

Hi, Alexander! First, please cc: such requests to maria-developers@ instead. Thanks! On Jan 22, Alexander Barkov wrote: > > Please review a patch for a crashing bug MDEV-5458. > > Item_func_min_max::get_date() did not always honor the flags > given (such as NO_ZERO_IN_DATE and NO_ZERO_DATE) > in could erroneously return a not-NULL value instead of NULL. > > The patch moves the call for check_date_with_warn() > *AFTER* conversion from DATETIME to TIME, to make > sure that the returned value always matches the requested > flags. > > Previously it was done before conversion. The value before > conversion could be OK for the flags given, but the value > after conversion could be not OK. > > Also, I added a new function adjust_time_range_with_warn() > to avoid duplicate code. Reused it in three places. All ok. Just one comment: > === modified file 'sql/mysql_priv.h' > --- sql/mysql_priv.h 2013-12-02 11:09:34 +0000 > +++ sql/mysql_priv.h 2014-01-22 14:53:38 +0000 > @@ -2582,6 +2582,7 @@ check_date(const MYSQL_TIME *ltime, ulon > } > bool check_date_with_warn(const MYSQL_TIME *ltime, uint fuzzy_date, > timestamp_type ts_type); > +bool adjust_time_range_with_warn(MYSQL_TIME *ltime, uint dec); > int test_if_number(char *str,int *res,bool allow_wildcards); > void change_byte(uchar *,uint,char,char); > bool init_read_record(READ_RECORD *info, THD *thd, TABLE *reg_form, This is 5.3, right? Take care when merging to 5.5, there's no mysql_priv.h there, only sql_priv.h and this declaration should not end up there, but in sql_time.h Regards, Sergei

2 1

Re: [Maria-developers] Rev 4019: MDEV-5505: Assertion `! is_set()' fails on PREPARE SELECT with out of range in GROUP BY
by Sergei Golubchik 26 Jan '14

26 Jan '14

Hi, Sanja! On Jan 23, sanja(a)askmonty.org wrote: > === modified file 'sql/sql_select.cc' > --- a/sql/sql_select.cc 2014-01-21 13:27:36 +0000 > +++ b/sql/sql_select.cc 2014-01-23 12:50:54 +0000 > @@ -20463,7 +20463,8 @@ find_order_in_list(THD *thd, Item **ref_ > if (!order_item->fixed && > (order_item->fix_fields(thd, order->item) || > (order_item= *order->item)->check_cols(1) || > - thd->is_fatal_error)) > + thd->is_fatal_error || > + thd->is_error())) > return TRUE; /* Wrong field. */ Why not simply > - thd->is_fatal_error)) > + thd->is_error())) can there be a fatal error that is not an error? :) Regards, Sergei

1 0

Re: [Maria-developers] [Commits] Rev 3965: MDEV-5403 - Reduce usage of LOCK_open: tc_count in lp:maria/10.0
by Kristian Nielsen 24 Jan '14

24 Jan '14

Sergey Vojtovich <svoj(a)mariadb.org> writes: > +#ifdef __cplusplus > +template <typename T, int S> class Atomic_type_triat; > + > + > +template <typename T> class Atomic_type_triat<T, 4> > +template <typename T> class Atomic_type_triat<T, 8> > +template <typename T, typename S= Atomic_type_triat<T, sizeof(T)> > class Atomic > + T operator++() { return add(1) + 1; } [lots and lots of more template code snipped] I am vetoing this. We really, _really_ do not want to package up the atomic stuff in even more abstractions and API layers than we already have. Atomics and lock-free stuff is in itself plenty complicated. It is crucial that one can at least see easily in the code what is going on, without also having to spend effort to understand multiple layers of wrapping. As far as I can see, the only thing the templates do is hide stuff (like the data type used and the wrapping in locks on platforms without atomic support?), while what we need is to make those details clear to people reading the code, not to hide them! - Kristian.

3 5

[Maria-developers] benchmarking next steps
by Axel Schwenke 23 Jan '14

23 Jan '14

Hi, for those of you who didn't attend the Barcelona meeting last week, here are the plans for next steps in benchmarking: 1. top priority is automatic running of DBT3 for each new release of MariaDB-10.0 and MySQL-5.6. Probably also for MariaDB-5.5. I'll send out another mail to pinpoint DBT3 conditions (i.e. which table statistics to use etc.) 2. multithreaded replication slave is now in a condition that it can and should be benchmarked 3. the problem pointed out by Yoshinori in http://yoshinorimatsunobu.blogspot.de/2013/12/single-thread-performance-reg… must be checked for MariaDB. Monty announced that he will commit a patch this week that should help with that problem. 4. for the NUMA scalability problem, Kristian will try to find the definitive reason with profiling tools. Besides that ad-hoc testing of new patches from Svoj continues as before. 5. Galera benchmarking will be done by the Galera team for now. XL

5 8

[Maria-developers] MariaDB 10.1 tree
by Sergei Petrunia 22 Jan '14

22 Jan '14

Hi, Unless there are any objections, I am going to create a 10.1 tree on Launchpad. It will be based on current 10.0. BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 3

[Maria-developers] packaging
by Leif Walsh 21 Jan '14

21 Jan '14

Hi all, How do you make debian and rpm packages for mariadb? Which are the "blessed" config files and how is the process automated (and how might I run it manually)? -- Cheers, Leif

2 2

Re: [Maria-developers] MDEV-5419 no audit events for warnings converted to errors in the strict mode
by Sergei Golubchik 21 Jan '14

21 Jan '14

Hi, Holyfoot! On Dec 15, holyfoot(a)askmonty.org wrote: > revno: 4005 > revision-id: holyfoot(a)askmonty.org-20131215112825-1a5p7fa6mwdoin26 > parent: sergii(a)pisem.net-20131213120038-hjea4r5zp7sjuq8l > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-5419 > timestamp: Sun 2013-12-15 15:28:25 +0400 > message: > MDEV-5419 no audit events for warnings converted to errors in the strict mode. > Plugins get error notifications only when my_message_sql() is called. > But errors are launched with THD::raise_condition() calls in other > places. These are push_warning(), implementations of SIGNAL and > RESIGNAL commands. > So it makes sence to notify plugins there in THD::raise_condition(). Looks ok. Please add test cases for MDEV-5419 and for MDEV-4846. Then ok to push. Regards, Sergei

1 0

Re: [Maria-developers] MDEV-5364 mysql_upgrade should be more verbose
by Sergei Golubchik 21 Jan '14

21 Jan '14

Hi, Holyfoot! On Dec 15, holyfoot(a)askmonty.org wrote: > At file:///home/hf/wmar/mdev-5364/ > > ------------------------------------------------------------ > revno: 4005 > revision-id: holyfoot(a)askmonty.org-20131215104419-ks2enrs2tds0z4ti > parent: sergii(a)pisem.net-20131213120038-hjea4r5zp7sjuq8l > committer: Alexey Botchkov <holyfoot(a)askmonty.org> > branch nick: mdev-5364 > timestamp: Sun 2013-12-15 14:44:19 +0400 > message: > MDEV-5364 mysql_upgrade should be more verbose. > If the check_version_match() fails during the mysql_upgrade > execution, it doesn't print the 'mysql' output. > So the printing of the output added to the check_version_match() > and also to the get_upgrade_info_file_name() functions. Looks ok, but I'd prefer to see a test case too. Can you please add it? Ok to push with a test case. Regards, Sergei

1 0

[Maria-developers] MariaDB plugin interface and embedded library compatibility
by Honza Horak 21 Jan '14

21 Jan '14

Hi guys, I'm not able to find any information about compatibility assurance of server side -- i.e plugin interface and libmysqld.so library. I expect both should have stable API at least for one minor version across bugfix releases, but I don't believe that libmysqld.so is able to preserve ABI compatibility, since the set of exported symbols there is really huge. Can you, please, provide some simple statement (ideally as an article) what is your best afford and if we can expect API/ABI of plugin/libmysqld.so interfaces? Thanks and regards, Honza

3 3

Re: [Maria-developers] [Commits] Rev 3963: MDEV-5426: Assertion `toku_ft_needed_unlocked(src_h)' failed (errno=11) ... in file:///home/psergey/chroot/saucy-x64/home/psergey/dev2/10.0/
by Sergei Petrunia 21 Jan '14

21 Jan '14

Hi Jan, On Tue, Jan 21, 2014 at 12:18:13PM +0200, Jan Lindström wrote: > Hi, > > While the original problem is tokudb related and below fix does > nicely address it and I'm sure that you did run regression testing, > my question is does below change have any affect on other storage > engines ? Why not add test case that is run all/most of the > supported storage engines ? The problem is that I am not aware of any location where I could add a test and then it would be run for every available storage engine. The effect of the change is that now EXPLAIN INSERT ... SELECT does not make a handler->start_bulk_insert() call that's not paired with a end_bulk_insert() call. > > R: Jan > > >At file:///home/psergey/chroot/saucy-x64/home/psergey/dev2/10.0/ > > > >------------------------------------------------------------ > >revno: 3963 > >revision-id: psergey(a)askmonty.org-20140121100256-pwiacbt684azw6kj > >parent: elenst(a)opensuse.home-20131228163657-kk32bmtqogy61mwm > >committer: Sergey Petrunya <psergey(a)askmonty.org> > >branch nick: 10.0 > >timestamp: Tue 2014-01-21 14:02:56 +0400 > >message: > > MDEV-5426: Assertion `toku_ft_needed_unlocked(src_h)' failed (errno=11) ... > > - the problem was caused by EXPLAIN INSERT SELECT. For that statement, > > the code would call select_insert::prepare2(), which would call > > handler->ha_start_bulk_insert(). The corresponding handler->end_bulk_insert() > > call is made from select_insert::send_eof or select_insert::abort_result_set > > which are never called for EXPLAIN INSERT SELECT. > > - Fixed by re-using approach of mysql-5.6: don't call ha_start_bulk_insert() if > > we are in EXPLAIN. > >=== modified file 'sql/sql_insert.cc' > >--- a/sql/sql_insert.cc 2013-12-16 12:02:21 +0000 > >+++ b/sql/sql_insert.cc 2014-01-21 10:02:56 +0000 > >@@ -3555,7 +3555,8 @@ int select_insert::prepare2(void) > > { > > DBUG_ENTER("select_insert::prepare2"); > > if (thd->lex->current_select->options & OPTION_BUFFER_RESULT && > >- thd->locked_tables_mode <= LTM_LOCK_TABLES) > >+ thd->locked_tables_mode <= LTM_LOCK_TABLES && > >+ !thd->lex->describe) > > table->file->ha_start_bulk_insert((ha_rows) 0); > > DBUG_RETURN(0); > > } > > > >=== added file 'storage/tokudb/mysql-test/tokudb_mariadb/r/mdev5426.result' > >--- a/storage/tokudb/mysql-test/tokudb_mariadb/r/mdev5426.result 1970-01-01 00:00:00 +0000 > >+++ b/storage/tokudb/mysql-test/tokudb_mariadb/r/mdev5426.result 2014-01-21 10:02:56 +0000 > >@@ -0,0 +1,6 @@ > >+CREATE TABLE t1 (i INT) ENGINE=TokuDB; > >+EXPLAIN INSERT INTO t1 SELECT * FROM t1; > >+id select_type table type possible_keys key key_len ref rows Extra > >+1 SIMPLE t1 ALL NULL NULL NULL NULL 1 Using temporary > >+INSERT INTO t1 SELECT * FROM t1; > >+DROP TABLE t1; > > > >=== added file 'storage/tokudb/mysql-test/tokudb_mariadb/t/mdev5426.test' > >--- a/storage/tokudb/mysql-test/tokudb_mariadb/t/mdev5426.test 1970-01-01 00:00:00 +0000 > >+++ b/storage/tokudb/mysql-test/tokudb_mariadb/t/mdev5426.test 2014-01-21 10:02:56 +0000 > >@@ -0,0 +1,10 @@ > >+ > >+CREATE TABLE t1 (i INT) ENGINE=TokuDB; > >+EXPLAIN INSERT INTO t1 SELECT * FROM t1; > >+ > >+--connect con1,localhost,root,,test > >+INSERT INTO t1 SELECT * FROM t1; > >+ > >+--connection default > >+--disconnect con1 > >+DROP TABLE t1; > > -- BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] New message from Yoshinori Matsunobu
by Kristian Nielsen 21 Jan '14

21 Jan '14

"Facebook" <notification+xxx(a)facebookmail.com> writes: > I read your latest blog post about profile-guided optisation, which is really interesting. > > I have one question.. What perf options/arguments did you use to get INST_RETIRED.ANY and ICACHE.MISSES ? perf stat -e cache-misses? I'm not sure what options give these numbers.. perf record -e r03c -e r1c2 -e rc0 -e r280 -c 250000 sql/mysqld ... INST_RETIRED.ANY is -e rc0. ICACHE.MISSES is r280. Note that except for a few, the performance counters are processer specific. The full list of available counters is found in "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2". Eg. the ones for Sandy Bridge are found in section 19.4: http://www.intel.com/content/www/us/en/processors/architectures-software-de… (For example, ICACHE.MISSES is umask=0x02 and eventnum=0x80, hence r280.) - Kristian.

1 0

Re: [Maria-developers] [Commits] Rev 3964: MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg in file:///home/psergey/dev2/10.0-fix1/
by Kristian Nielsen 20 Jan '14

20 Jan '14

Sergey Petrunya <psergey(a)askmonty.org> writes: > ------------------------------------------------------------ > revno: 3964 > revision-id: psergey(a)askmonty.org-20140120123657-g1z4g11xmsdiw2dc > committer: Sergey Petrunya <psergey(a)askmonty.org> > message: > MDEV-4816: rpl.rpl_trunc_temp fails in 10.0-serg > Undo the previous band-aid fix in psergey(a)askmonty.org-20130802141209-4dqfvx2db8acxwbl. > Kristian has made a proper fix, which uses a different approach. Thanks! - Kristian.

1 0

[Maria-developers] Top voted features for MariaDB 10.1
by Rasmus Johansson 19 Jan '14

19 Jan '14

Hi, Yesterday Daniel Bartholomew published a blog post about voting for features in MariaDB 10.1, https://blog.mariadb.org/what-do-you-want-to-see-in-mariadb-10-1/ . To make it easier to follow which the most wanted (most votes) features are I pulled together a list in JIRA for anyone interested. It can be found here https://mariadb.atlassian.net/secure/Dashboard.jspa?selectPageId=11500 . The page doesn't require login, but if you want to vote you need to log in. BR, Rasmus -- Rasmus Johansson, VP Engineering MariaDB | t: +358 50 499 9589 | Skype: ratzpo

2 1

[Maria-developers] problem with the linux thread pool in mariadb 5.5
by Rich Prohaska 16 Jan '14

16 Jan '14

we have a customer that has observed problems related to the interaction of the thread pools in mariadb 5.5.30 and tokudb 7.1.0. the problem is that connections that stuck for 100's of seconds in the Killed state when a big tokudb transaction commit is in progress. the customer claims that this problem was resolved by turning the thread pool OFF. have there been any fixes to the thread pool implementation post the 5.5.30 release? here is some information that may be useful. the processlist showed 2838 client connections of which: 851 Killed 483 Sleep 1467 Connect 1 show processlist 1 processing a commit on a big delete from a tokudb table 35 blocked on a row lock held by the big delete the Killed connections look like: 84847752 sfi_mysql 10.0.0.60:1814 sfi Killed 93 NULL 0.000 with the connection address and time slightly different a gdb snapshot of the system at the time of the failure: 291 total threads 130 threads waiting on fil_aio_wait 52 threads waiting on tokudb's work_on_kibbutz 16 thread tokudb deserialization thread waiting 36 mysql update thread blocked on the tokudb lock tree 1thread executing a big tokudb delete transaction 40 threads in the thread pool get_event function 1 tokudb checkpoint thread blocked waiting for the LP MO lock, which is held by the big txn commit thread that leaves 15 misc worker threads that are not doing anything interesting the gdb stacks for the thread pool threads are: Thread 78 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 71 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 70 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 69 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 68 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 62 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 57 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 52 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 51 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 49 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 45 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 44 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 43 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 42 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 41 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 39 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 37 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 36 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 35 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 33 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 32 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 31 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 26 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 24 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 22 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 21 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 20 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 19 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 18 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 17 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 16 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 13 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 12 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 11 : epoll_wait , io_poll_wait , listener , get_event , worker_main , start_thread , clone Thread 8 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 7 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 5 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 4 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 3 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone Thread 2 : pthread_cond_timedwait@@GLIBC_2.3.2 , inline_mysql_cond_timedwait , get_event , worker_main , start_thread , clone thanks rich prohaska

1 0

[Maria-developers] libmysqlclient.so and Fedora-specific symbol versioning
by Honza Horak 14 Jan '14

14 Jan '14

Hi guys, I'm writing this as a maintainer of MariaDB package in Fedora and RHEL. I've got some complaints about libmysqlclient symbols versioning in Fedora and future RHEL-7: https://bugzilla.redhat.com/show_bug.cgi?id=1045013 Simply put, the issue there is that RPMs (both made by MariaDB upstream or Fedora community) uses different symbol versioning than it is used in other distributions (deb packages, binary tar balls) or by other MySQL providers (Oracle, Percona). Fedora does it because it used to be done that way before and it was not changed at a time upstream changed that, since Fedora started to handle symbols list on its own. MariaDB upstream adopted Fedora's behavior as a resolution of the bug: https://mariadb.atlassian.net/browse/MDEV-3923 As a result, we have different versioning only based on packaging format now, which seems to be a problem. So, I'd like to propose to sync this gap between "RPM-based packages" and "rest of the world" in the future Fedora/RHEL releases, which basically means I'd like to ask: In case Fedora 21 and RHEL-7 adopt non-versioned symbols in libmysqlclient, would MariaDB upstream be able to do the same in RPMs for these releases? There is also second difference between RPM and non-RPM builds, which is that only limited subset of symbols (those that are documented as API) is exported in the client library in Fedora RPMs. This is because we believe exporting all symbols is wrong thing. Regarding this issue, we'd like to keep the limited set of symbols in RPMs, so, the only change I'm proposing to change versioning of these symbols (as described above). Primarily, I'd like to hear what MariaDB upstream's position on that is, if the sync can happen, but any ideas will be welcome. Honza

2 6

[Maria-developers] TokuDB INSERT NOAR / UPDATE NOAR
by Laurynas Biveinis 09 Jan '14

09 Jan '14

Hello - https://mariadb.com/kb/en/tokudb-differences/ says, for version 10: "No INSERT NOAR or UPDATE NOAR commands. We are working with Tokutek to improve this feature before adding it to MariaDB. " What improvements you are looking into? Are there any JIRA tasks to tracks? Thanks, -- Laurynas

1 0

[Maria-developers] Need Review: MDEV-5509: Seconds_behind_master incorrect in parallel replication in http://bazaar.launchpad.net/~maria-captains/maria/10.0
by Kristian Nielsen 08 Jan '14

08 Jan '14

Could someone review this patch for MDEV-5509? I am in particular worried that this might change some subtle behaviour of Seconds_Behind_Master in unexpected ways. Of course I tried my best to make sure such could not occur, but the semantics is really tricky and poorly documented, and I do not think we have good coverage in the test suite. So I would like to have one other developer check it carefully as well and see if I've missed something. - Kristian. knielsen(a)knielsen-hq.org writes: > At http://bazaar.launchpad.net/~maria-captains/maria/10.0 > > ------------------------------------------------------------ > revno: 3959 > revision-id: knielsen(a)knielsen-hq.org-20140108100044-iszrbhddvxkfne71 > parent: knielsen(a)knielsen-hq.org-20140107105703-sn31yvf80batk1yx > committer: knielsen(a)knielsen-hq.org > branch nick: mariadb-10.0-base > timestamp: Wed 2014-01-08 11:00:44 +0100 > message: > MDEV-5509: Seconds_behind_master incorrect in parallel replication > > The problem was a race between the SQL driver thread and the worker threads. > The SQL driver thread would set rli->last_master_timestamp to zero to > mark that it has caught up with the master, while the worker threads would > set it to the timestamp of the executed event. This can happen out-of-order > in parallel replication, causing the "caught up" status to be overwritten > and Seconds_Behind_Master to wrongly grow when the slave is idle. > > To fix, introduce a separate flag rli->sql_thread_caught_up to mark that the > SQL driver thread is caught up. This avoids issues with worker threads > overwriting the SQL driver thread status. In parallel replication, we then > make SHOW SLAVE STATUS check in addition that all worker threads are idle > before showing Seconds_Behind_Master as 0 due to slave idle. > === added file 'mysql-test/suite/rpl/r/rpl_parallel2.result' > --- a/mysql-test/suite/rpl/r/rpl_parallel2.result 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/suite/rpl/r/rpl_parallel2.result 2014-01-08 10:00:44 +0000 > @@ -0,0 +1,18 @@ > +include/rpl_init.inc [topology=1->2] > +*** MDEV-5509: Incorrect value for Seconds_Behind_Master if parallel replication *** > +SET @old_parallel_threads=@@GLOBAL.slave_parallel_threads; > +include/stop_slave.inc > +SET GLOBAL slave_parallel_threads=5; > +include/start_slave.inc > +CREATE TABLE t1 (a INT PRIMARY KEY, b INT); > +CALL mtr.add_suppression("Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system function that may return a different value on the slave"); > +INSERT INTO t1 VALUES (1,sleep(2)); > +Warnings: > +Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system function that may return a different value on the slave. > +Seconds_Behind_Master should be zero here because the slave is fully caught up and idle. > +Seconds_Behind_Master = '0' > +include/stop_slave.inc > +SET GLOBAL slave_parallel_threads=@old_parallel_threads; > +include/start_slave.inc > +DROP TABLE t1; > +include/rpl_end.inc > > === added file 'mysql-test/suite/rpl/t/rpl_parallel2.test' > --- a/mysql-test/suite/rpl/t/rpl_parallel2.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/suite/rpl/t/rpl_parallel2.test 2014-01-08 10:00:44 +0000 > @@ -0,0 +1,41 @@ > +--source include/have_binlog_format_statement.inc > +--let $rpl_topology=1->2 > +--source include/rpl_init.inc > + > +--echo *** MDEV-5509: Incorrect value for Seconds_Behind_Master if parallel replication *** > + > +--connection server_2 > +SET @old_parallel_threads=@@GLOBAL.slave_parallel_threads; > +--source include/stop_slave.inc > +SET GLOBAL slave_parallel_threads=5; > +--source include/start_slave.inc > + > +--connection server_1 > +CREATE TABLE t1 (a INT PRIMARY KEY, b INT); > +CALL mtr.add_suppression("Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. Statement is unsafe because it uses a system function that may return a different value on the slave"); > +--save_master_pos > + > +--connection server_2 > +--sync_with_master > + > +--connection server_1 > +INSERT INTO t1 VALUES (1,sleep(2)); > +--save_master_pos > + > +--connection server_2 > +--sync_with_master > + > +--echo Seconds_Behind_Master should be zero here because the slave is fully caught up and idle. > +--let $status_items= Seconds_Behind_Master > +--source include/show_slave_status.inc > + > + > +--connection server_2 > +--source include/stop_slave.inc > +SET GLOBAL slave_parallel_threads=@old_parallel_threads; > +--source include/start_slave.inc > + > +--connection server_1 > +DROP TABLE t1; > + > +--source include/rpl_end.inc > > === modified file 'sql/rpl_parallel.cc' > --- a/sql/rpl_parallel.cc 2014-01-03 11:20:53 +0000 > +++ b/sql/rpl_parallel.cc 2014-01-08 10:00:44 +0000 > @@ -766,6 +766,27 @@ rpl_parallel::wait_for_done() > } > > > +bool > +rpl_parallel::workers_idle() > +{ > + struct rpl_parallel_entry *e; > + uint32 i, max_i; > + > + max_i= domain_hash.records; > + for (i= 0; i < max_i; ++i) > + { > + bool active; > + e= (struct rpl_parallel_entry *)my_hash_element(&domain_hash, i); > + mysql_mutex_lock(&e->LOCK_parallel_entry); > + active= e->current_sub_id > e->last_committed_sub_id; > + mysql_mutex_unlock(&e->LOCK_parallel_entry); > + if (active) > + break; > + } > + return (i == max_i); > +} > + > + > /* > do_event() is executed by the sql_driver_thd thread. > It's main purpose is to find a thread that can execute the query. > > === modified file 'sql/rpl_parallel.h' > --- a/sql/rpl_parallel.h 2013-11-05 11:01:26 +0000 > +++ b/sql/rpl_parallel.h 2014-01-08 10:00:44 +0000 > @@ -117,6 +117,7 @@ struct rpl_parallel { > void reset(); > rpl_parallel_entry *find(uint32 domain_id); > void wait_for_done(); > + bool workers_idle(); > bool do_event(rpl_group_info *serial_rgi, Log_event *ev, > ulonglong event_size); > }; > > === modified file 'sql/rpl_rli.cc' > --- a/sql/rpl_rli.cc 2013-12-17 09:50:34 +0000 > +++ b/sql/rpl_rli.cc 2014-01-08 10:00:44 +0000 > @@ -56,7 +56,7 @@ Relay_log_info::Relay_log_info(bool is_s > is_fake(FALSE), > #endif > group_master_log_pos(0), log_space_total(0), ignore_log_space_limit(0), > - last_master_timestamp(0), slave_skip_counter(0), > + last_master_timestamp(0), sql_thread_caught_up(true), slave_skip_counter(0), > abort_pos_wait(0), slave_run_id(0), sql_driver_thd(), > inited(0), abort_slave(0), slave_running(0), until_condition(UNTIL_NONE), > until_log_pos(0), retried_trans(0), executed_entries(0), > @@ -1287,9 +1287,14 @@ void Relay_log_info::stmt_done(my_off_t > (probably ok - except in some very rare cases, only consequence > is that value may take some time to display in > Seconds_Behind_Master - not critical). > + > + In parallel replication, we take care to not set last_master_timestamp > + backwards, in case of out-of-order calls here. > */ > if (!(event_creation_time == 0 && > - IF_DBUG(debug_not_change_ts_if_art_event > 0, 1))) > + IF_DBUG(debug_not_change_ts_if_art_event > 0, 1)) && > + !(rgi->is_parallel_exec && event_creation_time <= last_master_timestamp) > + ) > last_master_timestamp= event_creation_time; > } > DBUG_VOID_RETURN; > > === modified file 'sql/rpl_rli.h' > --- a/sql/rpl_rli.h 2013-11-08 14:14:18 +0000 > +++ b/sql/rpl_rli.h 2014-01-08 10:00:44 +0000 > @@ -221,6 +221,12 @@ class Relay_log_info : public Slave_repo > bool sql_force_rotate_relay; > > time_t last_master_timestamp; > + /* > + The SQL driver thread sets this true while it is waiting at the end of the > + relay log for more events to arrive. SHOW SLAVE STATUS uses this to report > + Seconds_Behind_Master as zero while the SQL thread is so waiting. > + */ > + bool sql_thread_caught_up; > > void clear_until_condition(); > > > === modified file 'sql/slave.cc' > --- a/sql/slave.cc 2013-12-16 12:48:32 +0000 > +++ b/sql/slave.cc 2014-01-08 10:00:44 +0000 > @@ -2615,8 +2615,24 @@ static bool send_show_master_info_data(T > if ((mi->slave_running == MYSQL_SLAVE_RUN_CONNECT) && > mi->rli.slave_running) > { > - long time_diff= ((long)(time(0) - mi->rli.last_master_timestamp) > - - mi->clock_diff_with_master); > + long time_diff; > + bool idle; > + time_t stamp= mi->rli.last_master_timestamp; > + > + if (!stamp) > + idle= true; > + else > + { > + idle= mi->rli.sql_thread_caught_up; > + if (opt_slave_parallel_threads > 0 && idle && > + !mi->rli.parallel.workers_idle()) > + idle= false; > + } > + if (idle) > + time_diff= 0; > + else > + { > + time_diff= ((long)(time(0) - stamp) - mi->clock_diff_with_master); > /* > Apparently on some systems time_diff can be <0. Here are possible > reasons related to MySQL: > @@ -2632,13 +2648,15 @@ static bool send_show_master_info_data(T > slave is 2. At SHOW SLAVE STATUS time, assume that the difference > between timestamp of slave and rli->last_master_timestamp is 0 > (i.e. they are in the same second), then we get 0-(2-1)=-1 as a result. > - This confuses users, so we don't go below 0: hence the max(). > + This confuses users, so we don't go below 0. > > last_master_timestamp == 0 (an "impossible" timestamp 1970) is a > special marker to say "consider we have caught up". > */ > - protocol->store((longlong)(mi->rli.last_master_timestamp ? > - max(0, time_diff) : 0)); > + if (time_diff < 0) > + time_diff= 0; > + } > + protocol->store((longlong)time_diff); > } > else > { > @@ -6096,6 +6114,7 @@ static Log_event* next_event(rpl_group_i > > if (hot_log) > mysql_mutex_unlock(log_lock); > + rli->sql_thread_caught_up= false; > DBUG_RETURN(ev); > } > if (opt_reckless_slave) // For mysql-test > @@ -6133,12 +6152,10 @@ static Log_event* next_event(rpl_group_i > Seconds_Behind_Master would be zero only when master has no > more updates in binlog for slave. The heartbeat can be sent > in a (small) fraction of slave_net_timeout. Until it's done > - rli->last_master_timestamp is temporarely (for time of > - waiting for the following event) reset whenever EOF is > - reached. > + rli->sql_thread_caught_up is temporarely (for time of waiting for > + the following event) set whenever EOF is reached. > */ > - time_t save_timestamp= rli->last_master_timestamp; > - rli->last_master_timestamp= 0; > + rli->sql_thread_caught_up= true; > > DBUG_ASSERT(rli->relay_log.get_open_count() == > rli->cur_log_old_open_count); > @@ -6264,7 +6281,7 @@ static Log_event* next_event(rpl_group_i > rli->relay_log.wait_for_update_relay_log(rli->sql_driver_thd); > // re-acquire data lock since we released it earlier > mysql_mutex_lock(&rli->data_lock); > - rli->last_master_timestamp= save_timestamp; > + rli->sql_thread_caught_up= false; > continue; > } > /* > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0

[Maria-developers] Correct way to determine the ThreadPool usage
by Jean Weisbuch 07 Jan '14

07 Jan '14

Hello, I am counter-checking the mysqlreport "fork" i am maintening (https://mariadb.atlassian.net/browse/MDEV-573) so it could be included in Maria 10 before GA, i am actually unsure that i am checking correctly the Threadpool usage. For these stats (with thread_pool_max_threads=1200 and thread_handling=pool-of-threads) : +------------------------------------------+---------+ | Variable_name | Value | +------------------------------------------+---------+ | Threadpool_idle_threads | 47 | | Threadpool_threads | 52 | | Threads_cached | 0 | | Threads_connected | 19 | | Threads_created | 599771 | | Threads_running | 6 | +------------------------------------------+---------+ The actual output is : __ Threads ___________________________________________ Running 6 of 24 Created 599.77k 0.2/s Slow 0 0/s Threadpool 98 of 1200 %Used: 8.17 Running 52 of 1200 %Running: 4.33 Idle 46 of 1200 %Idle: 3.83 The formulae used are : Threadpool $stats{'Threadpool_threads'} + $stats{'Threadpool_idle_threads'}) of $vars{'thread_pool_max_threads'} %Used: percentage( ($stats{'Threadpool_threads'} + $stats{'Threadpool_idle_threads'}) / $vars{'thread_pool_max_threads'} Running $stats{'Threadpool_threads'} of $vars{'thread_pool_max_threads'} %Running: percentage($stats{'Threadpool_threads'} / $vars{'thread_pool_max_threads'}) Idle $stats{'Threadpool_idle_threads'} of $vars{'thread_pool_max_threads'} %Idle: percentage($stats{'Threadpool_idle_threads'} / $vars{'thread_pool_max_threads'}) Is the Threadpool usage calculation right or should only the Threadpool_threads status be used? What is the meaning of the Threads_connected value when the threadpool is used? Regards.

1 0

[Maria-developers] Elena please test: (MDEV-4974) memory leak in 5.5.32-MariaDB-1~wheezy-log
by Sergei Petrunia 03 Jan '14

03 Jan '14

Hi Elena, Could you please test the below? The changed code may affect - queries that use GROUP BY/ORDER BY/DISTINCT, or a combination of those. - correlated/uncorrelated subqueries. The subquery should remain a separate SELECT, i.e. it should not be converted into semi-join or optimized away. - combination of the above. The code adds a cleanup, so I expect a possible problem to be where we cleaned up something we shouldn't have. Most likely effects are either crash or wrong result. I don't think this patch has a chance of introducing a memory leak. ----- Forwarded message from "Sergei Petrunia (JIRA)" <jira(a)mariadb.atlassian.net> ----- Date: Fri, 3 Jan 2014 21:26:24 +0200 (EET) From: "Sergei Petrunia (JIRA)" <jira(a)mariadb.atlassian.net> To: psergey(a)montyprogram.com Subject: [JIRA] (MDEV-4974) memory leak in 5.5.32-MariaDB-1~wheezy-log [ https://mariadb.atlassian.net/browse/MDEV-4974?page=com.atlassian.jira.plug… ] Sergei Petrunia commented on MDEV-4974: ---------------------------------------- Elena, could you please test 5.5 tree, patched with psergey-fix-mdev4954.diff ? > memory leak in 5.5.32-MariaDB-1~wheezy-log > ------------------------------------------ > > Key: MDEV-4974 > URL: https://mariadb.atlassian.net/browse/MDEV-4974 > Project: MariaDB Development > Issue Type: Bug > Affects Versions: 5.5.32 > Environment: Debian Wheezy x86_64 > Linux greeneggs.lentz.com.au 3.9.3-x86_64-linode33 #1 SMP Mon May 20 10:22:57 EDT 2013 x86_64 GNU/Linux > Reporter: Daniel Black > Assignee: Sergei Petrunia > Priority: Critical > Fix For: 5.5.35 > > Attachments: allqueries.sql, catinthehat_memory-day_no_indexmerge.png, drupal.sql, green-eggs-mysql_connections-day.png, greeneggs-memory-day.png, greeneggs-memory-week.png, greeneggs-mysql_bin_relay_log-day.png, greeneggs-mysql_commands-day.png, greeneggs-mysql_files_tables-day.png, greeneggs-mysql_innodb_bpool-day.png, greeneggs-mysql_innodb_semaphores-day.png, greeneggs-mysql_innodb_tnx-day.png, greeneggs-mysql_myisam_indexes-day.png, greeneggs-mysql_qcache-day.png, greeneggs-mysql_select_types-day.png, greeneggs-mysql_sorts-day.png, greeneggs-mysql_table_locks-day.png, greeneggs-mysql_tmp_tables-day.png, leaks-track-allqueries.sql, leaks-track.sql, psergey-fix-mdev4954.diff, psergey-mdev4974-xpl1.diff, valgrind.mysqld.27336 > > > After running mariadb-5.5.32 in a multimaster for a few days its almost out of memory on the active master (the one getting all the reads). > The replication slave (same version) doesn't suffer the memory leak (with or without the replication filters defined). > Disabling the query cache on the active master may (was slightly off peak) have slowed the memory leak however it wasn't stopped. In the graph attached the query cache was disabled from Wed 5:30 to Thursday 03:00 > For greeneggs-mysql_commands-day.png the first drop is when query cache was turned back on. At the end I moved the active master to the other server. Other graphs are for this same time interval. > Memory usage calculation: > From http://dev.mysql.com/doc/refman/5.5/en/memory-use.html > per connection: > @read_buffer_size + @read_rnd_buffer_size + @sort_buffer_size + @join_buffer_size + @binlog_cache_size + @thread_stack + @@tmp_table_size = 19070976 > Max_used_connections 15 > Static component: > @key_buffer_size + @query_cache_size + @innodb_buffer_pool_size + @innodb_additional_mem_pool_size + @@innodb_log_buffer_size > 322961408 > select 15 * 19070976 + 322961408; = 609026048 > 609M max > From top: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 4532 mysql 20 0 1999m 1.4g 6072 S 4.0 71.9 1017:21 mysqld > I've still got the server running if more status is required. > show engine innodb status > ===================================== > 130830 0:46:23 INNODB MONITOR OUTPUT > ===================================== > Per second averages calculated from the last 17 seconds > ----------------- > BACKGROUND THREAD > ----------------- > srv_master_thread loops: 372124 1_second, 372076 sleeps, 37113 10_second, 1716 background, 1715 flush > srv_master_thread log flush and writes: 350597 > ---------- > SEMAPHORES > ---------- > OS WAIT ARRAY INFO: reservation count 999301, signal count 1149136 > Mutex spin waits 3647275, rounds 12020660, OS waits 198769 > RW-shared spins 896419, rounds 19893071, OS waits 574516 > RW-excl spins 68006, rounds 6887165, OS waits 204958 > Spin rounds per wait: 3.30 mutex, 22.19 RW-shared, 101.27 RW-excl > -------- > FILE I/O > -------- > I/O thread 0 state: waiting for completed aio requests (insert buffer thread) > I/O thread 1 state: waiting for completed aio requests (log thread) > I/O thread 2 state: waiting for completed aio requests (read thread) > I/O thread 3 state: waiting for completed aio requests (read thread) > I/O thread 4 state: waiting for completed aio requests (write thread) > I/O thread 5 state: waiting for completed aio requests (write thread) > Pending normal aio reads: 0 [0, 0] , aio writes: 0 [0, 0] , > ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0 > Pending flushes (fsync) log: 0; buffer pool: 0 > 7906118 OS file reads, 39186717 OS file writes, 23493355 OS fsyncs > 0.65 reads/s, 16384 avg bytes/read, 66.29 writes/s, 29.06 fsyncs/s > ------------------------------------- > INSERT BUFFER AND ADAPTIVE HASH INDEX > ------------------------------------- > Ibuf: size 1, free list len 287, seg size 289, 111478 merges > merged operations: > insert 106175, delete mark 100854, delete 13481 > discarded operations: > insert 0, delete mark 0, delete 0 > Hash table size 553229, node heap has 584 buffer(s) > 244.87 hash searches/s, 22.53 non-hash searches/s > --- > LOG > --- > Log sequence number 1981376581482 > Log flushed up to 1981376581482 > Last checkpoint at 1981376562791 > Max checkpoint age 84223550 > Checkpoint age target 81591565 > Modified age 18691 > Checkpoint age 18691 > 0 pending log writes, 0 pending chkp writes > 22419510 log i/o's done, 26.00 log i/o's/second > ---------------------- > BUFFER POOL AND MEMORY > ---------------------- > Total memory allocated 275644416; in additional pool allocated 0 > Total memory allocated by read views 136 > Internal hash tables (constant factor + variable factor) > Adaptive hash index 13998304 (4425832 + 9572472) > Page hash 277432 (buffer pool 0 only) > Dictionary cache 10287074 (1107952 + 9179122) > File system 648160 (82672 + 565488) > Lock system 665688 (664936 + 752) > Recovery system 0 (0 + 0) > Dictionary memory allocated 9179122 > Buffer pool size 16383 > Buffer pool size, bytes 268419072 > Free buffers 1 > Database pages 15798 > Old database pages 5811 > Modified db pages 97 > Pending reads 0 > Pending writes: LRU 0, flush list 0, single page 0 > Pages made young 10760065, not young 0 > 0.53 youngs/s, 0.00 non-youngs/s > Pages read 7903370, created 882751, written 16452888 > 0.65 reads/s, 0.00 creates/s, 39.47 writes/s > Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000 > Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s > LRU len: 15798, unzip_LRU len: 0 > I/O sum[1550]:cur[322], unzip sum[0]:cur[0] > -------------- > ROW OPERATIONS > -------------- > 0 queries inside InnoDB, 0 queries in queue > 1 read views open inside InnoDB > 0 transactions active inside InnoDB > 0 out of 1000 descriptors used > ---OLDEST VIEW--- > Normal read view > Read view low limit trx n:o 7D2D2F07 > Read view up limit trx id 7D2D2F07 > Read view low limit trx id 7D2D2F07 > Read view individually stored trx ids: > ----------------- > Main thread process no. 4532, id 140201824495360, state: sleeping > Number of rows inserted 1308400, updated 9736429, deleted 1227755, read 34888786828 > 1.00 inserts/s, 11.71 updates/s, 0.00 deletes/s, 249.22 reads/s > ------------------------ > LATEST DETECTED DEADLOCK > ------------------------ > 130830 0:27:15 > *** (1) TRANSACTION: > TRANSACTION 7D2C63D3, ACTIVE 0 sec starting index read > | Variable_name | Value | > | Aborted_clients | 57 | > | Aborted_connects | 0 | > | Access_denied_errors | 0 | > | Aria_pagecache_blocks_not_flushed | 0 | > | Aria_pagecache_blocks_unused | 15737 | > | Aria_pagecache_blocks_used | 3127 | > | Aria_pagecache_read_requests | 262055553 | > | Aria_pagecache_reads | 107163 | > | Aria_pagecache_write_requests | 69866678 | > | Aria_pagecache_writes | 0 | > | Aria_transaction_log_syncs | 0 | > | Binlog_commits | 12529081 | > | Binlog_group_commits | 12486299 | > | Binlog_snapshot_file | mariadb-bin.001408 | > | Binlog_snapshot_position | 57228334 | > | Binlog_bytes_written | 43273655871 | > | Binlog_cache_disk_use | 768128 | > | Binlog_cache_use | 12510967 | > | Binlog_stmt_cache_disk_use | 24 | > | Binlog_stmt_cache_use | 18077 | > | Busy_time | 0.000000 | > | Bytes_received | 60129853267 | > | Bytes_sent | 691695773018 | > | Com_admin_commands | 3809 | > | Com_assign_to_keycache | 0 | > | Com_alter_db | 0 | > | Com_alter_db_upgrade | 0 | > | Com_alter_event | 0 | > | Com_alter_function | 0 | > | Com_alter_procedure | 0 | > | Com_alter_server | 0 | > | Com_alter_table | 114 | > | Com_alter_tablespace | 0 | > | Com_analyze | 0 | > | Com_begin | 62278 | > | Com_binlog | 0 | > | Com_call_procedure | 0 | > | Com_change_db | 69728 | > | Com_change_master | 0 | > | Com_check | 1426 | > | Com_checksum | 0 | > | Com_commit | 45717 | > | Com_create_db | 1 | > | Com_create_event | 0 | > | Com_create_function | 0 | > | Com_create_index | 0 | > | Com_create_procedure | 1 | > | Com_create_server | 0 | > | Com_create_table | 42 | > | Com_create_trigger | 0 | > | Com_create_udf | 0 | > | Com_create_user | 0 | > | Com_create_view | 0 | > | Com_dealloc_sql | 24 | > | Com_delete | 388136 | > | Com_delete_multi | 5 | > | Com_do | 0 | > | Com_drop_db | 1 | > | Com_drop_event | 0 | > | Com_drop_function | 0 | > | Com_drop_index | 0 | > | Com_drop_procedure | 2 | > | Com_drop_server | 0 | > | Com_drop_table | 1 | > | Com_drop_trigger | 0 | > | Com_drop_user | 0 | > | Com_drop_view | 0 | > | Com_empty_query | 0 | > | Com_execute_sql | 24 | > | Com_flush | 6 | > | Com_grant | 0 | > | Com_ha_close | 0 | > | Com_ha_open | 0 | > | Com_ha_read | 0 | > | Com_help | 2 | > | Com_insert | 847948 | > | Com_insert_select | 551 | > | Com_install_plugin | 0 | > | Com_kill | 50 | > | Com_load | 0 | > | Com_lock_tables | 0 | > | Com_optimize | 0 | > | Com_preload_keys | 0 | > | Com_prepare_sql | 24 | > | Com_purge | 0 | > | Com_purge_before_date | 0 | > | Com_release_savepoint | 0 | > | Com_rename_table | 0 | > | Com_rename_user | 0 | > | Com_repair | 0 | > | Com_replace | 0 | > | Com_replace_select | 0 | > | Com_reset | 0 | > | Com_resignal | 0 | > | Com_revoke | 0 | > | Com_revoke_all | 0 | > | Com_rollback | 3 | > | Com_rollback_to_savepoint | 0 | > | Com_savepoint | 0 | > | Com_select | 47174988 | > | Com_set_option | 1189075 | > | Com_signal | 0 | > | Com_show_authors | 0 | > | Com_show_binlog_events | 3 | > | Com_show_binlogs | 1166 | > | Com_show_charsets | 0 | > | Com_show_client_statistics | 0 | > | Com_show_collations | 0 | > | Com_show_contributors | 0 | > | Com_show_create_db | 115 | > | Com_show_create_event | 0 | > | Com_show_create_func | 0 | > | Com_show_create_proc | 0 | > | Com_show_create_table | 4387 | > | Com_show_create_trigger | 0 | > | Com_show_databases | 7 | > | Com_show_engine_logs | 0 | > | Com_show_engine_mutex | 0 | > | Com_show_engine_status | 1167 | > | Com_show_events | 0 | > | Com_show_errors | 0 | > | Com_show_fields | 5721 | > | Com_show_function_status | 0 | > | Com_show_grants | 0 | > | Com_show_keys | 0 | > | Com_show_index_statistics | 0 | > | Com_show_master_status | 1 | > | Com_show_open_tables | 0 | > | Com_show_plugins | 0 | > | Com_show_privileges | 0 | > | Com_show_procedure_status | 0 | > | Com_show_processlist | 1039 | > | Com_show_profile | 0 | > | Com_show_profiles | 0 | > | Com_show_relaylog_events | 0 | > | Com_show_slave_hosts | 0 | > | Com_show_slave_status | 140780 | > | Com_show_status | 12670 | > | Com_show_storage_engines | 0 | > | Com_show_table_statistics | 0 | > | Com_show_table_status | 4287 | > | Com_show_tables | 6794 | > | Com_show_triggers | 4280 | > | Com_show_user_statistics | 0 | > | Com_show_variables | 2175 | > | Com_show_warnings | 0 | > | Com_slave_start | 10 | > | Com_slave_stop | 4 | > | Com_stmt_close | 24 | > | Com_stmt_execute | 24 | > | Com_stmt_fetch | 0 | > | Com_stmt_prepare | 24 | > | Com_stmt_reprepare | 0 | > | Com_stmt_reset | 0 | > | Com_stmt_send_long_data | 0 | > | Com_truncate | 0 | > | Com_uninstall_plugin | 0 | > | Com_unlock_tables | 2 | > | Com_update | 7082015 | > | Com_update_multi | 1 | > | Com_xa_commit | 0 | > | Com_xa_end | 0 | > | Com_xa_prepare | 0 | > | Com_xa_recover | 0 | > | Com_xa_rollback | 0 | > | Com_xa_start | 0 | > | Compression | OFF | > | Connections | 1164212 | > | Cpu_time | 0.000000 | > | Created_tmp_disk_tables | 2202858 | > | Created_tmp_files | 420678 | > | Created_tmp_tables | 5264753 | > | Delayed_errors | 0 | > | Delayed_insert_threads | 0 | > | Delayed_writes | 0 | > | Empty_queries | 14900340 | > | Executed_events | 0 | > | Executed_triggers | 0 | > | Feature_dynamic_columns | 0 | > | Feature_fulltext | 2 | > | Feature_gis | 28 | > | Feature_locale | 0 | > | Feature_subquery | 135848 | > | Feature_timezone | 6850 | > | Feature_trigger | 586 | > | Feature_xml | 0 | > | Flush_commands | 4 | > | Handler_commit | 63318523 | > | Handler_delete | 748245 | > | Handler_discover | 0 | > | Handler_icp_attempts | 71118314 | > | Handler_icp_match | 71108704 | > | Handler_mrr_init | 0 | > | Handler_mrr_key_refills | 0 | > | Handler_mrr_rowid_refills | 0 | > | Handler_prepare | 14968970 | > | Handler_read_first | 1155850 | > | Handler_read_key | 466199920 | > | Handler_read_last | 55346 | > | Handler_read_next | 27258307498 | > | Handler_read_prev | 8491322 | > | Handler_read_rnd | 66364460 | > | Handler_read_rnd_deleted | 1194 | > | Handler_read_rnd_next | 8174479457 | > | Handler_rollback | 21990 | > | Handler_savepoint | 0 | > | Handler_savepoint_rollback | 0 | > | Handler_tmp_update | 15018397 | > | Handler_tmp_write | 515819305 | > | Handler_update | 6481729 | > | Handler_write | 849123 | > | Innodb_adaptive_hash_cells | 553229 | > | Innodb_adaptive_hash_heap_buffers | 581 | > | Innodb_adaptive_hash_hash_searches | 1107671046 | > | Innodb_adaptive_hash_non_hash_searches | 249488632 | > | Innodb_background_log_sync | 350697 | > | Innodb_buffer_pool_pages_data | 15800 | > | Innodb_buffer_pool_bytes_data | 258867200 | > | Innodb_buffer_pool_pages_dirty | 295 | > | Innodb_buffer_pool_bytes_dirty | 4833280 | > | Innodb_buffer_pool_pages_flushed | 16456234 | > | Innodb_buffer_pool_pages_LRU_flushed | 48422 | > | Innodb_buffer_pool_pages_free | 1 | > | Innodb_buffer_pool_pages_made_not_young | 0 | > | Innodb_buffer_pool_pages_made_young | 10760117 | > | Innodb_buffer_pool_pages_misc | 582 | > | Innodb_buffer_pool_pages_old | 5812 | > | Innodb_buffer_pool_pages_total | 16383 | > | Innodb_buffer_pool_read_ahead_rnd | 0 | > | Innodb_buffer_pool_read_ahead | 2072088 | > | Innodb_buffer_pool_read_ahead_evicted | 91126 | > | Innodb_buffer_pool_read_requests | 10973288017 | > | Innodb_buffer_pool_reads | 5715842 | > | Innodb_buffer_pool_wait_free | 9 | > | Innodb_buffer_pool_write_requests | 132620870 | > | Innodb_checkpoint_age | 88015 | > | Innodb_checkpoint_max_age | 84223550 | > | Innodb_checkpoint_target_age | 81591565 | > | Innodb_data_fsyncs | 23497491 | > | Innodb_data_pending_fsyncs | 0 | > | Innodb_data_pending_reads | 0 | > | Innodb_data_pending_writes | 0 | > | Innodb_data_read | 129493962752 | > | Innodb_data_reads | 7906173 | > | Innodb_data_writes | 39194030 | > | Innodb_data_written | 586483447808 | > | Innodb_dblwr_pages_written | 16456234 | > | Innodb_dblwr_writes | 182242 | > | Innodb_deadlocks | 432 | > | Innodb_dict_tables | 1315 | > | Innodb_have_atomic_builtins | ON | > | Innodb_history_list_length | 3523 | > | Innodb_ibuf_discarded_delete_marks | 0 | > | Innodb_ibuf_discarded_deletes | 0 | > | Innodb_ibuf_discarded_inserts | 0 | > | Innodb_ibuf_free_list | 287 | > | Innodb_ibuf_merged_delete_marks | 100855 | > | Innodb_ibuf_merged_deletes | 13481 | > | Innodb_ibuf_merged_inserts | 106192 | > | Innodb_ibuf_merges | 111495 | > | Innodb_ibuf_segment_size | 289 | > | Innodb_ibuf_size | 1 | > | Innodb_log_waits | 0 | > | Innodb_log_write_requests | 73751900 | > | Innodb_log_writes | 22385577 | > | Innodb_lsn_current | 1981377626218 | > | Innodb_lsn_flushed | 1981377626218 | > | Innodb_lsn_last_checkpoint | 1981377538203 | > | Innodb_master_thread_1_second_loops | 372239 | > | Innodb_master_thread_10_second_loops | 37124 | > | Innodb_master_thread_background_loops | 1716 | > | Innodb_master_thread_main_flush_loops | 1715 | > | Innodb_master_thread_sleeps | 372191 | > | Innodb_max_trx_id | 2100117045 | > | Innodb_mem_adaptive_hash | 13965536 | > | Innodb_mem_dictionary | 10287074 | > | Innodb_mem_total | 275644416 | > | Innodb_mutex_os_waits | 198788 | > | Innodb_mutex_spin_rounds | 12021403 | > | Innodb_mutex_spin_waits | 3647342 | > | Innodb_oldest_view_low_limit_trx_id | 2100116933 | > | Innodb_os_log_fsyncs | 22425791 | > | Innodb_os_log_pending_fsyncs | 0 | > | Innodb_os_log_pending_writes | 0 | > | Innodb_os_log_written | 47227117568 | > | Innodb_page_size | 16384 | > | Innodb_pages_created | 882752 | > | Innodb_pages_read | 7903425 | > | Innodb_pages_written | 16456234 | > | Innodb_purge_trx_id | 2100116933 | > | Innodb_purge_undo_no | 0 | > | Innodb_row_lock_current_waits | 0 | > | Innodb_current_row_locks | 0 | > | Innodb_row_lock_time | 3209772 | > | Innodb_row_lock_time_avg | 74 | > | Innodb_row_lock_time_max | 31935 | > | Innodb_row_lock_waits | 43208 | > | Innodb_rows_deleted | 1227755 | > | Innodb_rows_inserted | 1308502 | > | Innodb_rows_read | 34888819968 | > | Innodb_rows_updated | 9738262 | > | Innodb_read_views_memory | 136 | > | Innodb_descriptors_memory | 8000 | > | Innodb_s_lock_os_waits | 574527 | > | Innodb_s_lock_spin_rounds | 19893402 | > | Innodb_s_lock_spin_waits | 896432 | > | Innodb_truncated_status_writes | 0 | > | Innodb_x_lock_os_waits | 204987 | > | Innodb_x_lock_spin_rounds | 6888035 | > | Innodb_x_lock_spin_waits | 68006 | > | Key_blocks_not_flushed | 0 | > | Key_blocks_unused | 5353 | > | Key_blocks_used | 4170 | > | Key_blocks_warm | 141 | > | Key_read_requests | 6295929 | > | Key_reads | 9626 | > | Key_write_requests | 21159 | > | Key_writes | 10962 | > | Last_query_cost | 0.000000 | > | Max_used_connections | 15 | > | Not_flushed_delayed_rows | 0 | > | Open_files | 142 | > | Open_streams | 0 | > | Open_table_definitions | 397 | > | Open_tables | 595 | > | Opened_files | 9756380 | > | Opened_table_definitions | 6425 | > | Opened_tables | 8666 | > | Opened_views | 0 | > | Performance_schema_cond_classes_lost | 0 | > | Performance_schema_cond_instances_lost | 0 | > | Performance_schema_file_classes_lost | 0 | > | Performance_schema_file_handles_lost | 0 | > | Performance_schema_file_instances_lost | 0 | > | Performance_schema_locker_lost | 0 | > | Performance_schema_mutex_classes_lost | 0 | > | Performance_schema_mutex_instances_lost | 0 | > | Performance_schema_rwlock_classes_lost | 0 | > | Performance_schema_rwlock_instances_lost | 0 | > | Performance_schema_table_handles_lost | 0 | > | Performance_schema_table_instances_lost | 0 | > | Performance_schema_thread_classes_lost | 0 | > | Performance_schema_thread_instances_lost | 0 | > | Prepared_stmt_count | 0 | > | Qcache_free_blocks | 6616 | > | Qcache_free_memory | 18486664 | > | Qcache_hits | 75724207 | > | Qcache_inserts | 8304484 | > | Qcache_lowmem_prunes | 1719071 | > | Qcache_not_cached | 2443705 | > | Qcache_queries_in_cache | 8992 | > | Qcache_total_blocks | 24978 | > | Queries | 142821923 | > | Questions | 133827961 | > | Rows_read | 35275818740 | > | Rows_sent | 1787826753 | > | Rows_tmp_read | 592687087 | > | Rpl_status | AUTH_MASTER | > | Select_full_join | 268533 | > | Select_full_range_join | 6393 | > | Select_range | 6218451 | > | Select_range_check | 0 | > | Select_scan | 3587397 | > | Slave_heartbeat_period | 1800.000 | > | Slave_open_temp_tables | 0 | > | Slave_received_heartbeats | 0 | > | Slave_retried_transactions | 0 | > | Slave_running | ON | > | Slow_launch_threads | 0 | > | Slow_queries | 3796864 | > | Sort_merge_passes | 269513 | > | Sort_range | 170798 | > | Sort_rows | 1870364969 | > | Sort_scan | 4917255 | > | Sphinx_error | | > | Sphinx_time | | > | Sphinx_total | | > | Sphinx_total_found | | > | Sphinx_word_count | | > | Sphinx_words | | > | Ssl_accept_renegotiates | 0 | > | Ssl_accepts | 0 | > | Ssl_callback_cache_hits | 0 | > | Ssl_cipher | | > | Ssl_cipher_list | | > | Ssl_client_connects | 0 | > | Ssl_connect_renegotiates | 0 | > | Ssl_ctx_verify_depth | 0 | > | Ssl_ctx_verify_mode | 0 | > | Ssl_default_timeout | 0 | > | Ssl_finished_accepts | 0 | > | Ssl_finished_connects | 0 | > | Ssl_session_cache_hits | 0 | > | Ssl_session_cache_misses | 0 | > | Ssl_session_cache_mode | NONE | > | Ssl_session_cache_overflows | 0 | > | Ssl_session_cache_size | 0 | > | Ssl_session_cache_timeouts | 0 | > | Ssl_sessions_reused | 0 | > | Ssl_used_session_cache_entries | 0 | > | Ssl_verify_depth | 0 | > | Ssl_verify_mode | 0 | > | Ssl_version | | > | Subquery_cache_hit | 4512 | > | Subquery_cache_miss | 3930 | > | Syncs | 4171361 | > | Table_locks_immediate | 85865730 | > | Table_locks_waited | 15 | > | Tc_log_max_pages_used | 0 | > | Tc_log_page_size | 0 | > | Tc_log_page_waits | 46 | > | Threadpool_idle_threads | 0 | > | Threadpool_threads | 0 | > | Threads_cached | 13 | > | Threads_connected | 2 | > | Threads_created | 15 | > | Threads_running | 2 | > | Uptime | 349494 | > | Uptime_since_flush_status | 349494 | > | Variable_name | Value | > | aria_block_size | 8192 | > | aria_checkpoint_interval | 30 | > | aria_checkpoint_log_activity | 1048576 | > | aria_force_start_after_recovery_failures | 0 | > | aria_group_commit | none | > | aria_group_commit_interval | 0 | > | aria_log_file_size | 1073741824 | > | aria_log_purge_type | immediate | > | aria_max_sort_file_size | 9223372036853727232 | > | aria_page_checksum | ON | > | aria_pagecache_age_threshold | 300 | > | aria_pagecache_buffer_size | 134217728 | > | aria_pagecache_division_limit | 100 | > | aria_recover | NORMAL | > | aria_repair_threads | 1 | > | aria_sort_buffer_size | 134217728 | > | aria_stats_method | nulls_unequal | > | aria_sync_log_dir | NEWFILE | > | aria_used_for_temp_tables | ON | > | auto_increment_increment | 2 | > | auto_increment_offset | 2 | > | autocommit | ON | > | automatic_sp_privileges | ON | > | back_log | 50 | > | basedir | /usr | > | big_tables | OFF | > | binlog_annotate_row_events | OFF | > | binlog_cache_size | 32768 | > | binlog_checksum | NONE | > | binlog_direct_non_transactional_updates | OFF | > | binlog_format | MIXED | > | binlog_optimize_thread_scheduling | ON | > | binlog_stmt_cache_size | 32768 | > | bulk_insert_buffer_size | 1048576 | > | character_set_client | latin1 | > | character_set_connection | latin1 | > | character_set_database | latin1 | > | character_set_filesystem | binary | > | character_set_results | latin1 | > | character_set_server | latin1 | > | character_set_system | utf8 | > | character_sets_dir | /usr/share/mysql/charsets/ | > | collation_connection | latin1_swedish_ci | > | collation_database | latin1_swedish_ci | > | collation_server | latin1_swedish_ci | > | completion_type | NO_CHAIN | > | concurrent_insert | ALWAYS | > | connect_timeout | 5 | > | datadir | /var/lib/mysql/ | > | date_format | %Y-%m-%d | > | datetime_format | %Y-%m-%d %H:%i:%s | > | deadlock_search_depth_long | 15 | > | deadlock_search_depth_short | 4 | > | deadlock_timeout_long | 50000000 | > | deadlock_timeout_short | 10000 | > | debug_no_thread_alarm | OFF | > | default_storage_engine | InnoDB | > | default_week_format | 0 | > | delay_key_write | ON | > | delayed_insert_limit | 100 | > | delayed_insert_timeout | 300 | > | delayed_queue_size | 1000 | > | div_precision_increment | 4 | > | engine_condition_pushdown | OFF | > | event_scheduler | OFF | > | expensive_subquery_limit | 100 | > | expire_logs_days | 3 | > | extra_max_connections | 1 | > | extra_port | 0 | > | flush | OFF | > | flush_time | 0 | > | foreign_key_checks | ON | > | ft_boolean_syntax | + -><()~*:""&| | > | ft_max_word_len | 84 | > | ft_min_word_len | 4 | > | ft_query_expansion_limit | 20 | > | ft_stopword_file | (built-in) | > | general_log | OFF | > | general_log_file | greeneggs.log | > | group_concat_max_len | 1024 | > | have_compress | YES | > | have_crypt | YES | > | have_csv | YES | > | have_dynamic_loading | YES | > | have_geometry | YES | > | have_innodb | YES | > | have_ndbcluster | NO | > | have_openssl | DISABLED | > | have_partitioning | YES | > | have_profiling | YES | > | have_query_cache | YES | > | have_rtree_keys | YES | > | have_ssl | DISABLED | > | have_symlink | YES | > | hostname | greeneggs.lentz.com.au | > | ignore_builtin_innodb | OFF | > | ignore_db_dirs | | > | init_connect | | > | init_file | | > | init_slave | | > | innodb_adaptive_flushing | ON | > | innodb_adaptive_flushing_method | estimate | > | innodb_adaptive_hash_index | ON | > | innodb_adaptive_hash_index_partitions | 1 | > | innodb_additional_mem_pool_size | 8388608 | > | innodb_autoextend_increment | 8 | > | innodb_autoinc_lock_mode | 1 | > | innodb_blocking_buffer_pool_restore | OFF | > | innodb_buffer_pool_instances | 1 | > | innodb_buffer_pool_populate | OFF | > | innodb_buffer_pool_restore_at_startup | 600 | > | innodb_buffer_pool_shm_checksum | ON | > | innodb_buffer_pool_shm_key | 0 | > | innodb_buffer_pool_size | 268435456 | > | innodb_change_buffering | all | > | innodb_checkpoint_age_target | 0 | > | innodb_checksums | ON | > | innodb_commit_concurrency | 0 | > | innodb_concurrency_tickets | 500 | > | innodb_corrupt_table_action | assert | > | innodb_data_file_path | ibdata1:10M:autoextend | > | innodb_data_home_dir | | > | innodb_dict_size_limit | 0 | > | innodb_doublewrite | ON | > | innodb_doublewrite_file | | > | innodb_fake_changes | OFF | > | innodb_fast_checksum | OFF | > | innodb_fast_shutdown | 1 | > | innodb_file_format | Antelope | > | innodb_file_format_check | ON | > | innodb_file_format_max | Antelope | > | innodb_file_per_table | ON | > | innodb_flush_log_at_trx_commit | 1 | > | innodb_flush_method | O_DIRECT | > | innodb_flush_neighbor_pages | area | > | innodb_force_load_corrupted | OFF | > | innodb_force_recovery | 0 | > | innodb_ibuf_accel_rate | 100 | > | innodb_ibuf_active_contract | 1 | > | innodb_ibuf_max_size | 134201344 | > | innodb_import_table_from_xtrabackup | 0 | > | innodb_io_capacity | 1000 | > | innodb_kill_idle_transaction | 0 | > | innodb_large_prefix | OFF | > | innodb_lazy_drop_table | 0 | > | innodb_lock_wait_timeout | 50 | > | innodb_locking_fake_changes | ON | > | innodb_locks_unsafe_for_binlog | OFF | > | innodb_log_block_size | 512 | > | innodb_log_buffer_size | 4194304 | > | innodb_log_file_size | 52428800 | > | innodb_log_files_in_group | 2 | > | innodb_log_group_home_dir | ./ | > | innodb_max_bitmap_file_size | 104857600 | > | innodb_max_changed_pages | 1000000 | > | innodb_max_dirty_pages_pct | 75 | > | innodb_max_purge_lag | 0 | > | innodb_merge_sort_block_size | 1048576 | > | innodb_mirrored_log_groups | 1 | > | innodb_old_blocks_pct | 37 | > | innodb_old_blocks_time | 0 | > | innodb_open_files | 400 | > | innodb_page_size | 16384 | > | innodb_print_all_deadlocks | OFF | > | innodb_purge_batch_size | 20 | > | innodb_purge_threads | 1 | > | innodb_random_read_ahead | OFF | > | innodb_read_ahead | linear | > | innodb_read_ahead_threshold | 56 | > | innodb_read_io_threads | 2 | > | innodb_recovery_stats | OFF | > | innodb_recovery_update_relay_log | OFF | > | innodb_replication_delay | 0 | > | innodb_rollback_on_timeout | OFF | > | innodb_rollback_segments | 128 | > | innodb_show_locks_held | 10 | > | innodb_show_verbose_locks | 0 | > | innodb_spin_wait_delay | 6 | > | innodb_stats_auto_update | 1 | > | innodb_stats_method | nulls_equal | > | innodb_stats_on_metadata | ON | > | innodb_stats_sample_pages | 8 | > | innodb_stats_update_need_lock | 1 | > | innodb_strict_mode | OFF | > | innodb_support_xa | ON | > | innodb_sync_spin_loops | 30 | > | innodb_table_locks | ON | > | innodb_thread_concurrency | 0 | > | innodb_thread_concurrency_timer_based | OFF | > | innodb_thread_sleep_delay | 10000 | > | innodb_track_changed_pages | OFF | > | innodb_use_atomic_writes | OFF | > | innodb_use_fallocate | OFF | > | innodb_use_global_flush_log_at_trx_commit | ON | > | innodb_use_native_aio | ON | > | innodb_use_sys_malloc | ON | > | innodb_use_sys_stats_table | OFF | > | innodb_version | 5.5.32-MariaDB-30.2 | > | innodb_write_io_threads | 2 | > | interactive_timeout | 28800 | > | join_buffer_size | 131072 | > | join_buffer_space_limit | 2097152 | > | join_cache_level | 2 | > | keep_files_on_create | OFF | > | key_buffer_size | 8388608 | > | key_cache_age_threshold | 300 | > | key_cache_block_size | 1024 | > | key_cache_division_limit | 100 | > | key_cache_segments | 0 | > | large_files_support | ON | > | large_page_size | 0 | > | large_pages | OFF | > | lc_messages | en_US | > | lc_messages_dir | /usr/share/mysql | > | lc_time_names | en_US | > | license | GPL | > | local_infile | ON | > | lock_wait_timeout | 31536000 | > | locked_in_memory | OFF | > | log | OFF | > | log_bin | ON | > | log_bin_trust_function_creators | OFF | > | log_error | | > | log_output | FILE | > | log_queries_not_using_indexes | ON | > | log_slave_updates | ON | > | log_slow_filter | admin,filesort,filesort_on_disk,full_join,full_scan,query_cache,query_cache_miss,tmp_table,tmp_table_on_disk | > | log_slow_queries | ON | > | log_slow_rate_limit | 1 | > | log_slow_verbosity | query_plan | > | log_warnings | 2 | > | long_query_time | 3.000000 | > | low_priority_updates | OFF | > | lower_case_file_system | OFF | > | lower_case_table_names | 0 | > | master_verify_checksum | OFF | > | max_allowed_packet | 16777216 | > | max_binlog_cache_size | 18446744073709547520 | > | max_binlog_size | 104857600 | > | max_binlog_stmt_cache_size | 18446744073709547520 | > | max_connect_errors | 10 | > | max_connections | 100 | > | max_delayed_threads | 20 | > | max_error_count | 64 | > | max_heap_table_size | 16777216 | > | max_insert_delayed_threads | 20 | > | max_join_size | 18446744073709551615 | > | max_length_for_sort_data | 1024 | > | max_long_data_size | 16777216 | > | max_prepared_stmt_count | 16382 | > | max_relay_log_size | 0 | > | max_seeks_for_key | 4294967295 | > | max_sort_length | 1024 | > | max_sp_recursion_depth | 0 | > | max_tmp_tables | 32 | > | max_user_connections | 0 | > | max_write_lock_count | 4294967295 | > | metadata_locks_cache_size | 1024 | > | min_examined_row_limit | 0 | > | mrr_buffer_size | 262144 | > | multi_range_count | 256 | > | myisam_block_size | 1024 | > | myisam_data_pointer_size | 6 | > | myisam_max_sort_file_size | 9223372036853727232 | > | myisam_mmap_size | 18446744073709551615 | > | myisam_recover_options | BACKUP,QUICK | > | myisam_repair_threads | 1 | > | myisam_sort_buffer_size | 536870912 | > | myisam_stats_method | nulls_unequal | > | myisam_use_mmap | OFF | > | net_buffer_length | 16384 | > | net_read_timeout | 30 | > | net_retry_count | 10 | > | net_write_timeout | 60 | > | old | OFF | > | old_alter_table | OFF | > | old_passwords | OFF | > | open_files_limit | 2159 | > | optimizer_prune_level | 1 | > | optimizer_search_depth | 62 | > | optimizer_switch | index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off | > | performance_schema | OFF | > | performance_schema_events_waits_history_long_size | 10000 | > | performance_schema_events_waits_history_size | 10 | > | performance_schema_max_cond_classes | 80 | > | performance_schema_max_cond_instances | 1000 | > | performance_schema_max_file_classes | 50 | > | performance_schema_max_file_handles | 32768 | > | performance_schema_max_file_instances | 10000 | > | performance_schema_max_mutex_classes | 200 | > | performance_schema_max_mutex_instances | 1000000 | > | performance_schema_max_rwlock_classes | 30 | > | performance_schema_max_rwlock_instances | 1000000 | > | performance_schema_max_table_handles | 100000 | > | performance_schema_max_table_instances | 50000 | > | performance_schema_max_thread_classes | 50 | > | performance_schema_max_thread_instances | 1000 | > | pid_file | /var/run/mysqld/mysqld.pid | > | plugin_dir | /usr/lib/mysql/plugin/ | > | plugin_maturity | unknown | > | port | 3306 | > | preload_buffer_size | 32768 | > | profiling | OFF | > | profiling_history_size | 15 | > | progress_report_time | 56 | > | protocol_version | 10 | > | query_alloc_block_size | 8192 | > | query_cache_limit | 131072 | > | query_cache_min_res_unit | 4096 | > | query_cache_size | 33554432 | > | query_cache_strip_comments | OFF | > | query_cache_type | ON | > | query_cache_wlock_invalidate | OFF | > | query_prealloc_size | 8192 | > | range_alloc_block_size | 4096 | > | read_buffer_size | 1048576 | > | read_only | ON | > | read_rnd_buffer_size | 524288 | > | relay_log | | > | relay_log_index | | > | relay_log_info_file | relay-log.info | > | relay_log_purge | ON | > | relay_log_recovery | OFF | > | relay_log_space_limit | 0 | > | replicate_annotate_row_events | OFF | > | replicate_do_db | | > | replicate_do_table | | > | replicate_events_marked_for_skip | replicate | > | replicate_ignore_db | | > | replicate_ignore_table | peoplesforum.cache | > | replicate_wild_do_table | | > | replicate_wild_ignore_table | peoplesforum.cache% | > | report_host | greeneggs | > | report_password | | > | report_port | 3306 | > | report_user | | > | rowid_merge_buff_size | 8388608 | > | rpl_recovery_rank | 0 | > | secure_auth | OFF | > | secure_file_priv | | > | server_id | 12302 | > | skip_external_locking | ON | > | skip_name_resolve | ON | > | skip_networking | OFF | > | skip_show_database | OFF | > | slave_compressed_protocol | OFF | > | slave_exec_mode | STRICT | > | slave_load_tmpdir | /tmp | > | slave_max_allowed_packet | 1073741824 | > | slave_net_timeout | 3600 | > | slave_skip_errors | 1062 | > | slave_sql_verify_checksum | ON | > | slave_transaction_retries | 10 | > | slave_type_conversions | | > | slow_launch_time | 2 | > | slow_query_log | ON | > | slow_query_log_file | /var/log/mysql/mariadb-slow.log | > | socket | /var/run/mysqld/mysqld.sock | > | sort_buffer_size | 262144 | > | sql_auto_is_null | OFF | > | sql_big_selects | ON | > | sql_big_tables | OFF | > | sql_buffer_result | OFF | > | sql_log_bin | ON | > | sql_log_off | OFF | > | sql_low_priority_updates | OFF | > | sql_max_join_size | 18446744073709551615 | > | sql_mode | NO_ENGINE_SUBSTITUTION | > | sql_notes | ON | > | sql_quote_show_create | ON | > | sql_safe_updates | OFF | > | sql_select_limit | 18446744073709551615 | > | sql_slave_skip_counter | 0 | > | sql_warnings | OFF | > | ssl_ca | | > | ssl_capath | | > | ssl_cert | | > | ssl_cipher | | > | ssl_key | | > | storage_engine | InnoDB | > | stored_program_cache | 256 | > | sync_binlog | 3 | > | sync_frm | ON | > | sync_master_info | 0 | > | sync_relay_log | 0 | > | sync_relay_log_info | 0 | > | system_time_zone | UTC | > | table_definition_cache | 400 | > | table_open_cache | 1024 | > | thread_cache_size | 128 | > | thread_concurrency | 10 | > | thread_handling | one-thread-per-connection | > | thread_pool_idle_timeout | 60 | > | thread_pool_max_threads | 500 | > | thread_pool_oversubscribe | 3 | > | thread_pool_size | 8 | > | thread_pool_stall_limit | 500 | > | thread_stack | 294912 | > | time_format | %H:%i:%s | > | time_zone | SYSTEM | > | timed_mutexes | OFF | > | tmp_table_size | 16777216 | > | tmpdir | /tmp | > | transaction_alloc_block_size | 8192 | > | transaction_prealloc_size | 4096 | > | tx_isolation | REPEATABLE-READ | > | unique_checks | ON | > | updatable_views_with_limit | YES | > | userstat | OFF | > | version | 5.5.32-MariaDB-1~wheezy-log | > | version_comment | mariadb.org binary distribution | > | version_compile_machine | x86_64 | > | version_compile_os | debian-linux-gnu | > | wait_timeout | 600 | > I'm planning on doing a debug build from MDEV-572 and maybe try to get valgrind to narrow it down (if that doesn't bring the server to a total halt). Better suggestions welcome. -- This message was sent by Atlassian JIRA (v6.2-OD-05-4#6207) ----- End forwarded message -----

1 0

[Maria-developers] MDEV-5115 review
by Kristian Nielsen 02 Jan '14

02 Jan '14

Hi Serg, Here is my review of your MDEV-5115 patch. First, a general comment: Another way to fix this would be a smaller patch. It would not attempt to implement anything related to the new event types. Instead, it would just have a small bit of code that allows to read the binary format of the new event types, but it would represent them internally as the old type, just ignoring any of the extra information, which appears to be currently unused outside of NDB. Probably then it would also make sense to not implement the renaming of the old event types. There would just be three extra cases in Log_event::read_log_event(), and a bit of extra code in the *_rows_log_event construstructors to be able to ignore any extra info. However, I do not really have much against your approach of doing a partial merge to get code that is closer to what is in MySQL, if you prefer that. I mention it because we discussed briefly already on IRC whether a smaller patch could be enough. A few detailed comments below. Otherwise, while I would have probably done the minimal patch myself, I am ok with this way also. So ok to push after fixing the few commit and code comments mentioned below. - Kristian. > ------------------------------------------------------------ > revno: 3921 > revision-id: sergii(a)pisem.net-20131203192301-afokgpslfq0f3xg8 > parent: sergii(a)pisem.net-20131201111624-xe3f1ul6otcyvyom > fixes bug: https://mariadb.atlassian.net/browse/MDEV-5115 > committer: Sergei Golubchik <sergii(a)pisem.net> > branch nick: 10.0 > timestamp: Tue 2013-12-03 20:23:01 +0100 > message: > MDEV-5115 RBR from MySQL 5.6 to MariaDB 10.0 does not work > > Patially merge WL#5917, to understand v2 row events "Partially merge WL#5917, which introduces new event types for row-based binlogging. This is needed to be able to replicate from a >=5.6 MySQL master to a MariaDB slave." > === modified file 'mysql-test/suite/binlog/t/binlog_old_versions.test' > --- mysql-test/suite/binlog/t/binlog_old_versions.test 2013-04-09 21:27:41 +0000 > +++ mysql-test/suite/binlog/t/binlog_old_versions.test 2013-12-03 19:23:01 +0000 > @@ -24,6 +24,17 @@ > > source include/not_embedded.inc; > > +--echo ==== Read binlog with v2 row events ==== > + > +# Read binlog. > +--exec $MYSQL_BINLOG --local-load=$MYSQLTEST_VARDIR/tmp/ suite/binlog/std_data/ver_trunk_row_v2.001 | $MYSQL --local-infile=1 > +# Show result. > +SELECT * FROM t1 ORDER BY a; > +SELECT * FROM t2 ORDER BY a; > +SELECT COUNT(*) FROM t3; > +# Reset. > +DROP TABLE t1, t2, t3; > + > > --echo ==== Read modern binlog (version 5.1.23) ==== > Is this the only test we have of reading the v2 row event types? I think it is not a particularly good test, as it tests mysqlbinlog reading them, while the interesting thing is a slave receiving them from the master. Even though some code is shared between the two there are lots of differences as well. The better test would be to install the pre-generated binlog file manually on a master and have the slave replicate it. However, it is easy to end up spending too much time on setting up these replication tests and getting them to work reliably on all platforms, so maybe not worth it. Maybe a good compromise is to instead ask Elena to test it manually against a real MySQL 5.6 server - after all, that is the actual case we want to work. > === modified file 'sql/log_event.h' > --- sql/log_event.h 2013-11-01 11:00:11 +0000 > +++ sql/log_event.h 2013-12-03 19:23:01 +0000 > @@ -659,11 +663,11 @@ enum Log_event_type > PRE_GA_DELETE_ROWS_EVENT = 22, > > /* > - These event numbers are used from 5.1.16 and forward > + These event numbers are used from 5.1.16 until mysql-trunk-xx Please change this comment to explain the actual situation. Ie. that they are used in MariaDB, but not in MySQL >= 5.6. > @@ -677,6 +681,20 @@ enum Log_event_type > HEARTBEAT_LOG_EVENT= 27, > > /* > + In some situations, it is necessary to send over ignorable > + data to the slave: data that a slave can handle in case there > + is code for handling it, but which can be ignored if it is not > + recognized. > + */ > + IGNORABLE_LOG_EVENT= 28, > + ROWS_QUERY_LOG_EVENT= 29, Add a comment that these are MySQL 5.6 events that are unimplemented in MariaDB. (Do we need another MDEV to be able to replicate against a MySQL master that produces ROWS_QUERY_LOG_EVENT? It is quite similar to our ANNOTATE_ROWS_EVENT, IIRC). > + /* Version 2 of the Row events */ > + WRITE_ROWS_EVENT = 30, > + UPDATE_ROWS_EVENT = 31, > + DELETE_ROWS_EVENT = 32, Add comment that these are only generated by MySQL 5.6.

2 1

[Maria-developers] review: [Commits] Rev 3917: MDEV-9095: Executing triggers on slave in row-based replication in file:///home/bell/maria/bzr/work-maria-10.0-MDEV-5095/
by Michael Widenius 19 Dec '13

19 Dec '13

Hi! > === modified file 'sql/log_event.cc' > === modified file 'sql/sql_delete.cc' > --- a/sql/sql_delete.cc 2013-10-16 09:38:42 +0000 > +++ b/sql/sql_delete.cc 2013-12-19 08:10:00 +0000 > @@ -525,12 +525,7 @@ bool mysql_delete(THD *thd, TABLE_LIST * > table->triggers->has_triggers(TRG_EVENT_DELETE, > TRG_ACTION_AFTER)) > { > - /* > - The table has AFTER DELETE triggers that might access to subject table > - and therefore might need delete to be done immediately. So we turn-off > - the batching. > - */ > - (void) table->file->extra(HA_EXTRA_DELETE_CANNOT_BATCH); > + table->prepare_triggers_for_delete_stmt_or_event(); > will_batch= FALSE; > } In the above code, you check for this twice: table->triggers->has_triggers(TRG_EVENT_DELETE, TRG_ACTION_AFTER)) Would be better to have prepare_triggers_for_delete_stmt_or_event() return 1 if we have delete triggers and do: if (table->prepare_triggers_for_delete_stmt_or_event()) will_batch= FALSE; else will_batch= ... <cut> > === modified file 'sql/sql_update.cc' > --- a/sql/sql_update.cc 2013-10-16 09:38:42 +0000 > +++ b/sql/sql_update.cc 2013-12-19 08:10:00 +0000 > @@ -707,12 +707,7 @@ int mysql_update(THD *thd, > table->triggers->has_triggers(TRG_EVENT_UPDATE, > TRG_ACTION_AFTER)) > { > - /* > - The table has AFTER UPDATE triggers that might access to subject > - table and therefore might need update to be done immediately. > - So we turn-off the batching. > - */ > - (void) table->file->extra(HA_EXTRA_UPDATE_CANNOT_BATCH); > + table->prepare_triggers_for_update_stmt_or_event(); > will_batch= FALSE; > } Same here. Regards, Monty

1 0

[Maria-developers] review of mdev-5095 (executing triggers on slave)
by Michael Widenius 19 Dec '13

19 Dec '13

Hi! Here is the review of mdev-5095 I got the diff from: bzr diff -r3942.. > === modified file 'mysql-test/r/mysqld--help.result' > --- mysql-test/r/mysqld--help.result 2012-10-18 21:33:06 +0000 > +++ mysql-test/r/mysqld--help.result 2013-12-03 10:53:01 +0000 > @@ -747,6 +747,14 @@ > --slave-net-timeout=# > Number of seconds to wait for more data from a > master/slave connection before aborting the read > + --slave-run-triggers-for-rbr=name > + Modes for how triggers in row-base replication on slave > + side will be executed. Legal values are NO (default), YES > + and LOGGING. NO means that trigger for RBR will not be > + running on slave YES and LOGGING means that triggers will > + be running on slave (if there was not triggers running on > + the naster), LOGGING also mens that flag about executed > + triggers will be written to binlog. Suggested new text: --slave-run-triggers-for-rbr=name Modes for how triggers in row-base replication on slave side will be executed. Legal values are NO (default), YES and LOGGING. NO means that trigger for RBR will not be running on slave. YES and LOGGING means that triggers will be running on slave, if there was not triggers running on the master for the statement. LOGGING also means that the executed triggers will be written to binlog. <cut> > === modified file 'sql/log_event.cc' <cut> > -#if !defined(MYSQL_CLIENT) && defined(HAVE_REPLICATION) > +#if defined(MYSQL_SERVER) && defined(HAVE_REPLICATION) Was the above needed or mostly an optimization? > + > +static void restore_empty_query_table_list(LEX *lex) > +{ > + if (lex->first_not_own_table()) > + (*lex->first_not_own_table()->prev_global)= NULL; > + lex->query_tables= NULL; > + lex->query_tables_last= &lex->query_tables; > +} Add a comment of what is the purpose of the above function. > @@ -8340,6 +8351,22 @@ int Rows_log_event::do_apply_event(Relay > /* A small test to verify that objects have consistent types */ > DBUG_ASSERT(sizeof(thd->variables.option_bits) == sizeof(OPTION_RELAXED_UNIQUE_CHECKS)); > > + if (slave_run_triggers_for_rbr) > + { > + LEX *lex= thd->lex; > + uint8 new_trg_event_map= get_trg_event_map(); > + > + DBUG_ASSERT(lex->query_tables == NULL); > + if ((lex->query_tables= rli->tables_to_lock)) > + rli->tables_to_lock->prev_global= &lex->query_tables; Add a comment why we have to set prev_global (not obvious). It's also not obvious why restore_empty_tables() is not resetting rli->tables_to_lock->prev_global as it's reseting the the rest of the changed things. > @@ -8429,8 +8462,11 @@ int Rows_log_event::do_apply_event(Relay > */ > TABLE_LIST *ptr= rli->tables_to_lock; > for (uint i=0 ; ptr && (i < rli->tables_to_lock_count); ptr= ptr->next_global, i++) > + { > const_cast<Relay_log_info*>(rli)->m_table_map.set_table(ptr->table_id, ptr->table); > - What does this test really do ? (I was quickly checking the code to understand what m_table_id stands for, but it was not obvious). > + if (m_table_id == ptr->table_id) > + master_had_triggers= ((RPL_TABLE_LIST*)ptr)->master_had_triggers; <cut> > if (table) > { > bool transactional_table= table->file->has_transactions(); > @@ -8618,6 +8656,9 @@ int Rows_log_event::do_apply_event(Relay > */ > thd->reset_current_stmt_binlog_format_row(); > thd->is_slave_error= 1; > + /* remove trigger's tables */ > + if (slave_run_triggers_for_rbr) > + restore_empty_query_table_list(thd->lex); > DBUG_RETURN(error); > } You do the above 'restore_empty_query_table_list(thd->lex);' before every return in this function, except the last return. - Isn't it better to do a 'error:' tag at the end of the function to ensure we don't miss any cases ? - Add a comment why we don't need to do this at the very end of Rows_log_event::do_apply_event(). Something like: /* We don't have to call restore_empty_query_table_list() here as it's called in rows_event_stmt_cleanup(). */ When is lex->query_tables used? Is it only used by 'open' ? If yes, isn't it enough to always reset it after the 'open' call? > @@ -9773,6 +9831,29 @@ Write_rows_log_event::do_before_row_oper > from the start. > */ > } > + if (slave_run_triggers_for_rbr && !master_had_triggers && m_table->triggers ) > + { > + if (m_table->triggers->has_triggers(TRG_EVENT_DELETE, > + TRG_ACTION_AFTER)) > + { > + /* > + The table has AFTER DELETE triggers that might access to > + subject table and therefore might need delete to be done > + immediately. So we turn-off the batching. > + */ > + (void) m_table->file->extra(HA_EXTRA_DELETE_CANNOT_BATCH); > + } > + if (m_table->triggers->has_triggers(TRG_EVENT_UPDATE, > + TRG_ACTION_AFTER)) > + { > + /* > + The table has AFTER UPDATE triggers that might access to subject > + table and therefore might need update to be done immediately. > + So we turn-off the batching. > + */ > + (void) m_table->file->extra(HA_EXTRA_UPDATE_CANNOT_BATCH); > + } > + } Good that you noticed and fixed the above. However, why not just call the function prepare_triggers_for_insert_stmt() that does exactly the same thing? <cut> > @@ -10749,6 +10894,17 @@ Delete_rows_log_event::do_before_row_ope > */ > return 0; > } > + if (slave_run_triggers_for_rbr && !master_had_triggers && m_table->triggers && > + m_table->triggers->has_triggers(TRG_EVENT_DELETE, > + TRG_ACTION_AFTER)) > + { > + /* > + The table has AFTER DELETE triggers that might access to subject table > + and therefore might need delete to be done immediately. So we turn-off > + the batching. > + */ > + (void) m_table->file->extra(HA_EXTRA_DELETE_CANNOT_BATCH); > + } Would be better if we could do a function 'prepare_triggers_for_delete_stmt()' and use the same code here and in sql_delete.cc <cut> > @@ -10877,6 +11049,18 @@ Update_rows_log_event::do_before_row_ope > > m_table->timestamp_field_type= TIMESTAMP_NO_AUTO_SET; > > + if (slave_run_triggers_for_rbr && !master_had_triggers && m_table->triggers && > + m_table->triggers->has_triggers(TRG_EVENT_UPDATE, > + TRG_ACTION_AFTER)) > + { > + /* > + The table has AFTER UPDATE triggers that might access to subject > + table and therefore might need update to be done immediately. > + So we turn-off the batching. > + */ > + (void) m_table->file->extra(HA_EXTRA_UPDATE_CANNOT_BATCH); > + } > + Would be better if we could do a function 'prepare_triggers_for_update_stmt()' and use the same code here and in sql_update.cc <cut> Regards, Monty

2 4

[Maria-developers] FW: Rev 3758: MDEV-5470: Cost-based subquery item pushdown must take into account semi-joins
by Sergei Petrunia 19 Dec '13

19 Dec '13

Hi Timour, Please find below a patch that should implement execution-time protection against malfunction between condition moving and semi-joins. There needs also to be an optimization-time counterpart, which should have the same logic. Will you code it yourself or want me to? ----- Forwarded message from Sergei Petrunia <psergey(a)askmonty.org> ----- Date: Thu, 19 Dec 2013 02:49:22 +0400 From: Sergei Petrunia <psergey(a)askmonty.org> To: commits(a)mariadb.org Subject: Rev 3758: MDEV-5470: Cost-based subquery item pushdown must take into account semi-joins At http://bazaar.launchpad.net/~maria-captains/maria/10.0-mdev83 ------------------------------------------------------------ revno: 3758 committer: Sergey Petrunya <psergey(a)askmonty.org> branch nick: 10.0-mdev83 timestamp: Thu 2013-12-19 06:50:28 +0400 message: MDEV-5470: Cost-based subquery item pushdown must take into account semi-joins - When moving expensive conditions, take into account that semi-joins limit where they can be moved. - This is only execution part in JOIN::setup_dynamic_conditions(). Optimization part is not yet present. - No testcases yet. - Moving inside SJ-Materialization nests doesn't seem to be supported (either before this patch or after. This patch itself does take SJ-Materialization into account) === modified file 'sql/item_cmpfunc.cc' --- sql/item_cmpfunc.cc 2013-11-01 11:10:38 +0000 +++ sql/item_cmpfunc.cc 2013-12-19 02:50:28 +0000 @@ -6591,6 +6591,8 @@ void Item_func_collect_stats::dbug_print } #endif /*DBUG_OFF*/ +JOIN_TAB *find_last_tab_for_dynamic_cond(table_map cond_tables, + JOIN *join, JOIN_TAB *join_tab); Item_func_dynamic_cond::Item_func_dynamic_cond(Item *cond, JOIN_TAB *atab, JOIN_TAB **ctab) : Item_func_collect_stats(cond) @@ -6624,13 +6626,15 @@ Item_func_dynamic_cond::Item_func_dynami if (active_tab->bush_root_tab) { first_tab= active_tab->bush_root_tab->bush_children->start; - last_tab= active_tab->bush_root_tab->bush_children->end; + //last_tab= active_tab->bush_root_tab->bush_children->end; } else { first_tab= join->join_tab + join->const_tables; - last_tab= join->join_tab + join->top_join_tab_count; + //last_tab= join->join_tab + join->top_join_tab_count; } + last_tab= find_last_tab_for_dynamic_cond(cond->used_tables(), + active_tab->join, active_tab); DBUG_ASSERT(active_tab >= first_tab && active_tab < last_tab); === modified file 'sql/item_cmpfunc.h' --- sql/item_cmpfunc.h 2013-10-18 19:56:55 +0000 +++ sql/item_cmpfunc.h 2013-12-19 02:50:28 +0000 @@ -561,14 +561,20 @@ class Item_func_collect_stats : public I class Item_func_dynamic_cond : public Item_func_collect_stats { -protected: +protected: // as if there were any ancestor classes? List<Item_subselect> subqueries; /* The join_tab where the condition is currently 'pushed'.*/ st_join_table *active_tab; /* The join_tab currently being executed. */ st_join_table **exec_tab; /* The boundaries of the sub-plan where this predicate can be pushed. */ - st_join_table *first_tab, *last_tab; + st_join_table *first_tab; + st_join_table *last_tab; //psergey-todo: this should point to the last tab. + // conditions depending on semi-join tables have + // limits re. how far they can be moved. +public: + inline st_join_table * get_last_tab() { return last_tab; } +protected: /* The relative access cost based on optimizer estimates. This is the cost of all access methods per one record from the first table in the plan. === modified file 'sql/opt_subselect.cc' --- sql/opt_subselect.cc 2013-11-04 15:56:09 +0000 +++ sql/opt_subselect.cc 2013-12-19 02:50:28 +0000 @@ -1480,6 +1480,7 @@ static bool convert_subq_to_sj(JOIN *par sj_nest->sj_subq_pred= subq_pred; sj_nest->original_subq_pred_used_tables= subq_pred->used_tables() | subq_pred->left_expr->used_tables(); + sj_nest->sj_strategys_join_tab= uint(-1); /* Nests do not participate in those 'chains', so: */ /* sj_nest->next_leaf= sj_nest->next_local= sj_nest->next_global == NULL*/ emb_join_list->push_back(sj_nest); @@ -4321,6 +4322,21 @@ int init_dups_weedout(JOIN *join, uint f /* + For each SJ-inner table in [start_tab; end_tab], set emb_sj_nest to idx +*/ +static void update_sj_strategys_join_tab(JOIN_TAB *start_tab, + JOIN_TAB *end_tab, + uint idx) +{ + for (JOIN_TAB *j= start_tab; j < end_tab; j++) + { + TABLE_LIST *emb_nest; + if ((emb_nest= j->emb_sj_nest)) + emb_nest->sj_strategys_join_tab= idx; + } +} + +/* Setup the strategies to eliminate semi-join duplicates. SYNOPSIS @@ -4448,6 +4464,10 @@ int setup_semijoin_dups_elimination(JOIN for (uint j= i; j < i + pos->n_sj_tables; j++) join->join_tab[j].inside_loosescan_range= TRUE; + + update_sj_strategys_join_tab(join->join_tab + i, + join->join_tab + i + pos->n_sj_tables, + i + pos->n_sj_tables - 1); /* Calculate key length */ keylen= 0; @@ -4461,6 +4481,7 @@ int setup_semijoin_dups_elimination(JOIN tab[pos->n_sj_tables - 1].do_firstmatch= tab; i+= pos->n_sj_tables; pos+= pos->n_sj_tables; + break; } case SJ_OPT_DUPS_WEEDOUT: @@ -4503,6 +4524,9 @@ int setup_semijoin_dups_elimination(JOIN break; } } + update_sj_strategys_join_tab(join->join_tab + i, + join->join_tab + i + pos->n_sj_tables, + i + pos->n_sj_tables - 1); init_dups_weedout(join, first_table, i, i + pos->n_sj_tables - first_table); i+= pos->n_sj_tables; @@ -4558,6 +4582,9 @@ int setup_semijoin_dups_elimination(JOIN } } j[-1].do_firstmatch= jump_to; + update_sj_strategys_join_tab(join->join_tab + i, + join->join_tab + i + pos->n_sj_tables, + i + pos->n_sj_tables - 1); i+= pos->n_sj_tables; pos+= pos->n_sj_tables; === modified file 'sql/sql_select.cc' --- sql/sql_select.cc 2013-11-08 12:36:02 +0000 +++ sql/sql_select.cc 2013-12-19 02:50:28 +0000 @@ -24608,8 +24608,8 @@ double JOIN::static_pushdown_cost(uint i @param pred the predicate to be wrapped in Item_func_dynamic_cond @param init_tab the initial 'active' JOIN_TAB where the dynamic predicate is pushed to - @param cur_tab pointer to the JOIN_TAB* that stores the current JOIN_TAB - during execution + @param active_tab_ptr pointer to the JOIN_TAB* that stores the current JOIN_TAB + during execution */ static Item_func_collect_stats * wrap_with_dynamic_conds(Item *pred, JOIN_TAB *init_tab, JOIN_TAB **active_tab_ptr, @@ -24674,6 +24674,81 @@ wrap_with_dynamic_conds(Item *pred, JOIN } +/* + @brief Find the last JOIN_TAB that a condition can be attached. + + + @param cond_tables used_tables() of the condition that we intend to move. + @param join_tab The left-most join tab where the condition can be + attached (in other words, default attachment point) + + @detail + In a regular inner join, one can take a condition that is attached to a + table $T, and move it to any table that comes after $T. + + When semi-joins are present, this is no longer true. Detailed explanation + can be found in maria-developers@, email "Movable conditions and semi-joins". + In short: + + - Inside an SJ-Materialization nest, a condition can be moved to any table to + the right, but it must stay within the nest. (We don't support nested + semi-joins, so one will not find semi-joins inside an SJ-M nest) + + - All other Semi-Join strategies have a "range" where they apply. If a + condition depends on a table that is within a semi-join, it must not be + moved over the right edge of the range. +*/ + +JOIN_TAB *find_last_tab_for_dynamic_cond(table_map cond_tables, + JOIN *join, JOIN_TAB *join_tab) +{ + if (join_tab->bush_root_tab) + { + /* + We are inside SJ-Materialization nest. There are no semi-joins here, + return the last tab in the nest. + */ + return join_tab->bush_root_tab->bush_children->end; + } + + /* Start from the right-most bound */ + uint last_tab = join->top_join_tab_count; + + cond_tables= cond_tables & ~(PSEUDO_TABLE_BITS | join->const_table_map); + /* + Walk through semi-joins that this table depends on, and check their last + join tabs. The smallest last join tab sets the limit about how far right + the condition can be moved. + */ + Table_map_iterator tm_it(cond_tables); + int tableno; + while ((tableno = tm_it.next_bit()) != Table_map_iterator::BITMAP_END) + { + TABLE_LIST *sj_nest; + if ((sj_nest= join->map2table[tableno]->emb_sj_nest)) + { + if (sj_nest->is_active_sjm()) + { + /* + Whoa this condition also depends on a table from within + SJ-Materialization nest. (Can happen possible because of equality + propagation/substitution). If we didn't return earlier in this + function, we're not inside a semi-join nest. A value that depends + on a table within a SJ-Materialization nest means that it depends on + the materialized table columns. + */ + continue; + } + + if (sj_nest->sj_strategys_join_tab != uint(-1) && + sj_nest->sj_strategys_join_tab < last_tab) + last_tab= sj_nest->sj_strategys_join_tab; + } + } + return join->join_tab + last_tab; +} + + /** Make expensive subqueries dynamically pushdownable. */ @@ -24703,7 +24778,12 @@ bool JOIN::setup_dynamic_conditions() Update the least cardinality join_tab for each tab for the chosen join order. Check if there are any conditions at all that need to be made dynamic. */ - min_tab= NULL; + min_tab= NULL; + /* + psergey-todo: the following loop should walk inside SJ-Materialization + nests, too. Maybe, this whole function should be invoked for each + SJ-Materilization nest. + */ for (tab= last_tab - 1; tab >= first_tab; tab--) { if (optimizer_flag(thd, OPTIMIZER_SWITCH_STATIC_COND_PUSHDOWN)) @@ -24746,7 +24826,8 @@ bool JOIN::setup_dynamic_conditions() */ for (tab= first_tab; tab < last_tab; tab++) { - Item_func_collect_stats *wrapped_select_cond= NULL, *cur_wrapped_cond; + Item_func_collect_stats *wrapped_select_cond= NULL; + Item_func_dynamic_cond *cur_wrapped_cond; if (tab->select_cond && !(wrapped_select_cond= @@ -24800,14 +24881,29 @@ bool JOIN::setup_dynamic_conditions() Add all dynamic conditions pushed to previous JOIN_TABs also to the current JOIN_TAB. This allows to "move" a dynamic condition from one tab to another by enabling it for the corrseponding tab. + + psergey-todo: conditions have limits on how far to the right they can be + moved (Item_func_dynamic_cond::last_tab). Don't attach conditions to + where they can't be moved. */ if (!prev_dynamic_conds.is_empty()) { - List_iterator_fast<Item_func_dynamic_cond> dyn_cond_it(prev_dynamic_conds); - if (!wrapped_select_cond) - wrapped_select_cond= dyn_cond_it++; + List_iterator<Item_func_dynamic_cond> dyn_cond_it(prev_dynamic_conds); while ((cur_wrapped_cond= dyn_cond_it++)) - wrapped_select_cond->add_pred(cur_wrapped_cond); + { + if (!wrapped_select_cond) + wrapped_select_cond= cur_wrapped_cond; + else + wrapped_select_cond->add_pred(cur_wrapped_cond); + + /* + psergey-todo: conditions have limits on how far to the right they can be + moved (Item_func_dynamic_cond::last_tab). Don't attach conditions to + where they can't be moved. + */ + if (cur_wrapped_cond->get_last_tab() == tab) + dyn_cond_it.remove(); + } } prev_dynamic_conds.concat(&cur_dynamic_conds); cur_dynamic_conds.empty(); === modified file 'sql/table.h' --- sql/table.h 2013-09-25 18:07:06 +0000 +++ sql/table.h 2013-12-19 02:50:28 +0000 @@ -1721,6 +1721,9 @@ struct TABLE_LIST table_map sj_inner_tables; /* Number of IN-compared expressions */ uint sj_in_exprs; + + //psergey-todo: add the index of last table in the join order + uint sj_strategys_join_tab; /* If this is a non-jtbm semi-join nest: corresponding subselect predicate */ Item_in_subselect *sj_subq_pred; ----- End forwarded message ----- -- BR Sergei -- Sergei Petrunia, Software Developer MariaDB | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MariaDB r3955 make fail; " error: ‘isfinite’ was not declared in this scope"
by darx＠sent.com 18 Dec '13

18 Dec '13

hi, upgrading a MariaDB 10/git src build from r3911 -> r3955, on x86_64 after configure, make fails with a warning & an error @, ... [ 19%] Building CXX object storage/connect/CMakeFiles/connect.dir/ha_connect.cc.o cd /usr/local/src/mariadb/bld/storage/connect && /usr/bin/g++-4.8 -DFORCE_INIT_OF_VARS -DHAVE_CONFIG_H -DHUGE_SUPPORT -DLIBXML2_SUPPORT -DLINUX -DMARIADB -DMYSQL_DYNAMIC_PLUGIN -DMYSQL_SUPPORT -DODBC_SUPPORT -DPIVOT_SUPPORT -DUBUNTU -DUNIX -DZIP_SUPPORT -Dconnect_EXPORTS -Wall -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=amdfam10 -mtune=amdfam10 -std=c++11 -felide-constructors -fno-exceptions -fno-rtti -Wall -Wno-unused-parameter -fno-exceptions -fno-rtti -fpermissive -fexceptions -fPIC -O2 -g -DNDEBUG -DDBUG_OFF -DMY_PTHREAD_FASTMUTEX=1 -fPIC -I/usr/local/src/mariadb/bld/include -I/usr/include/libxml2 -I/usr/local/src/mariadb/include -I/usr/local/src/mariadb/sql -I/usr/local/src/mariadb/bld/pcre -I/usr/local/src/mariadb/pcre -I/usr/local/ssl/include -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -march=amdfam10 -mtune=amdfam10 -Wall -Wmissing-declarations -Wno-write-strings -Wno-unused-variable -Wno-unused-value -Wno-unused-function -Wno-parentheses -o CMakeFiles/connect.dir/ha_connect.cc.o -c /usr/local/src/mariadb/storage/connect/ha_connect.cc In file included from /usr/local/src/mariadb/sql/gcalc_tools.h:21:0, from /usr/local/src/mariadb/sql/spatial.h:28, from /usr/local/src/mariadb/sql/item.h:3667, from /usr/local/src/mariadb/sql/sql_lex.h:26, from /usr/local/src/mariadb/sql/sql_class.h:463, from /usr/local/src/mariadb/storage/connect/ha_connect.cc:104: /usr/local/src/mariadb/sql/gcalc_slicescan.h:29:40: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix] #define GCALC_DBUG_ENTER(a) DBUG_ENTER("Gcalc "a) ^ In file included from /usr/local/src/mariadb/sql/item.h:3669:0, from /usr/local/src/mariadb/sql/sql_lex.h:26, from /usr/local/src/mariadb/sql/sql_class.h:463, from /usr/local/src/mariadb/storage/connect/ha_connect.cc:104: /usr/local/src/mariadb/sql/item_func.h: In member function ‘double Item_func::check_float_overflow(double)’: /usr/local/src/mariadb/sql/item_func.h:281:26: error: ‘isfinite’ was not declared in this scope return isfinite(value) ? value : raise_float_overflow(); ^ /usr/local/src/mariadb/sql/item_func.h:281:26: note: suggested alternative: In file included from /usr/include/c++/4.8/random:38:0, from /usr/include/c++/4.8/bits/stl_algo.h:65, from /usr/include/c++/4.8/algorithm:62, from /usr/local/src/mariadb/sql/mdl.h:32, from /usr/local/src/mariadb/sql/table.h:22, from /usr/local/src/mariadb/sql/field.h:29, from /usr/local/src/mariadb/sql/unireg.h:172, from /usr/local/src/mariadb/sql/sql_class.h:24, from /usr/local/src/mariadb/storage/connect/ha_connect.cc:104: /usr/include/c++/4.8/cmath:596:5: note: ‘std::isfinite’ isfinite(_Tp __x) ^ make[2]: *** [storage/connect/CMakeFiles/connect.dir/ha_connect.cc.o] Error 1 make[2]: Leaving directory `/usr/local/src/mariadb/bld' make[1]: *** [storage/connect/CMakeFiles/connect.dir/all] Error 2 make[1]: Leaving directory `/usr/local/src/mariadb/bld' make: *** [all] Error 2

1 0

Re: [Maria-developers] metadata_lock_info plugin
by Sergey Vojtovich 13 Dec '13

13 Dec '13

Hi Kentoku, thanks for your contribution and sorry for this long delay. I finally managed to go through your code. The most important thing I'm worried about is that there is no protection of ticket lists: lists may be updated while we iterate them and it may cause server crash in concurrent environment. From what I can see MDL_context is mostly supposed to be accessed only by thread which owns this context. As such it is not protected by any locks. I believe we should use global lists instead, something like: mysql_mutex_lock(&mdl_locks.m_mutex); iterate mdl_locks.m_locks (hash of MDL_lock) { mysql_prlock_rdlock(&lock->m_rwlock); iterate lock->m_granted (list of MDL_ticket) { // store data } mysql_prlock_unlock(&lock->m_rwlock); } mysql_mutex_lock(&mdl_locks.m_mutex); A few more suggestions in no particular order: - instead of making m_tickets public I'd suggest to try to make i_s_metadata_lock_info_fill_table() a friend function (shouldn't be relevant anymore) - why check for thd->killed? (shouldn't be relevant anymore) - metadata_lock_info_lock_mode_length[] includes ending zero, and then we store e.g. "MDL_SHARED\0" whereas we should store "MDL_SHARED" I'd suggest to declare these arrays as following: static const LEX_STRING metadata_lock_info_lock_mode_str[]= { STRING_WITH_LEN("MDL_INTENTION_EXCLUSIVE"), // or C_STRING_WITH_LEN() ... }; - Roberto suggests to rename ID to THREAD_ID and I agree - Roberto suggests to add QUERY_ID column and I agree - Roberto suggests to add LOCK_DURATION column and I agree - Roberto suggests to use m_namespace_to_wait_state_name instead of metadata_lock_info_lock_names, but I tend to disagree because the former says "Waiting for...". Though I'd suggest to make array of LEX_STRING's to avoid calling strdup(). - Roberto suggests to replace DB with KEY and NAME with SUB_KEY, but I tend to disagree since in most cases it is db and table name. I'd vote for TABLE_SCHEMA and TABLE_NAME to stay in line with the rest I_S tables. Regards, Sergey On Mon, Jul 01, 2013 at 03:46:22AM +0900, kentoku wrote: > Hi Sergey, > Sorry. I think this plugin needs more locks "mdl_locks.m_mutex", > "mdl_locks.m_global_lock" and "mdl_locks.m_commit_lock". Is it right? Would > you please teach me how can I use it? > Thanks, > Kentoku > > > 2013/7/1 kentoku <kentokushiba(a)gmail.com> > > > Hi Sergey, > > > > I made new information schema plugin which named "metadata_lock_info" > > plugin. This plugin makes it possible knowing "who has metadata locks". In > > development stage, sometimes DBAs meet metadata locks when using alter > > table statement. This metadata locks are sometimes caused by GUI tools. In > > service stage, sometimes DBAs meet metadata locks when using alter table > > statement. This metadata locks are sometimes caused by long batch > > processing. In many cases, the DBAs need to judge immediately. So I made it > > for all DBAs. > > Would you please review this plugin? > > lp:~kentokushiba/maria/10.0.3-metadata_lock_info > > Note: This plugin needs a change of sql/mdl.h > > > > Thanks, > > Kentoku > >

3 15

Re: [Maria-developers] Rev 3915: MDEV-5388 - Reduce usage of LOCK_open: unused_tables
by Sergei Golubchik 12 Dec '13

12 Dec '13

Hi, Sergey! Did you benchmark the improvement you get with this patch? On Dec 05, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 3915 > revision-id: svoj(a)mariadb.org-20131205084430-7rt735tbanw0i6uq > parent: svoj(a)mariadb.org-20130827121233-b9mguuxctnjlq5wd > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Thu 2013-12-05 12:44:30 +0400 > message: > MDEV-5388 - Reduce usage of LOCK_open: unused_tables > > Removed unused_tables, find LRU object by timestamp instead. > === modified file 'sql/table_cache.cc' > --- a/sql/table_cache.cc 2013-08-27 12:12:33 +0000 > +++ b/sql/table_cache.cc 2013-12-05 08:44:30 +0000 > @@ -324,20 +248,44 @@ void tc_add_table(THD *thd, TABLE *table > DBUG_ASSERT(table->in_use == thd); > mysql_mutex_lock(&LOCK_open); > table->s->tdc.all_tables.push_front(table); > - tc_count++; > /* If we have too many TABLE instances around, try to get rid of them */ > - if (tc_count > tc_size && unused_tables) > + if (tc_count == tc_size) I'd rather put (tc_count >= tc_size), looks safer. > { > - TABLE *purge_table= unused_tables; > - tc_remove_table(purge_table); > - mysql_rwlock_rdlock(&LOCK_flush); > + TDC_iterator tdc_it; > mysql_mutex_unlock(&LOCK_open); > - intern_close_table(purge_table); > - mysql_rwlock_unlock(&LOCK_flush); > - check_unused(thd); > + > + tdc_it.init(); > + mysql_mutex_lock(&LOCK_open); > + if (tc_count == tc_size) and here > + { > + TABLE *purge_table= 0; > + TABLE_SHARE *share; I think a status variable for this would be nice. So that one could make an informed decision about the desired size of the cache. > + while ((share= tdc_it.next())) > + { > + TABLE_SHARE::TABLE_list::Iterator it(share->tdc.free_tables); > + TABLE *entry; > + while ((entry= it++)) > + if (!purge_table || entry->tc_time < purge_table->tc_time) > + purge_table= entry; > + } > + if (purge_table) > + { > + tdc_it.deinit(); > + purge_table->s->tdc.free_tables.remove(purge_table); > + purge_table->s->tdc.all_tables.remove(purge_table); > + mysql_rwlock_rdlock(&LOCK_flush); > + mysql_mutex_unlock(&LOCK_open); > + intern_close_table(purge_table); > + mysql_rwlock_unlock(&LOCK_flush); > + check_unused(thd); > + return; > + } > + } > + tdc_it.deinit(); Okay, so you only purge one table at time? Since purge is kind of an expensive operation, it's better to amortize the cost of it by purging many tables at once. > } > - else > - mysql_mutex_unlock(&LOCK_open); > + /* Nothing to evict, increment tc_count. */ > + tc_count++; > + mysql_mutex_unlock(&LOCK_open); > } > 2 Regards, Sergei

2 6

Re: [Maria-developers] Rev 3914: MDEV-4956 - Reduce usage of LOCK_open: TABLE_SHARE::tdc.used_tables
by Sergei Golubchik 12 Dec '13

12 Dec '13

Hi, Sergey! On Dec 10, Sergey Vojtovich wrote: > At lp:maria/10.0 > > ------------------------------------------------------------ > revno: 3914 > revision-id: svoj(a)mariadb.org-20131210150036-0hwh1gy4z3jalwsg > parent: bar(a)mnogosearch.org-20131203101253-mbz05d9jtkb3iycp > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0-mdev4956 > timestamp: Tue 2013-12-10 19:00:36 +0400 > message: > MDEV-4956 - Reduce usage of LOCK_open: TABLE_SHARE::tdc.used_tables > > - tc_acquire_table and tc_release_table do not access > TABLE_SHARE::tdc.used_tables anymore > - in tc_acquire_table(): release LOCK_tdc after we relase LOCK_open > (saves a few CPU cycles in critical section) > - in tc_release_table(): if we reached table cache threshold, evict > to-be-released table without moving it to unused_tables. unused_tables > must be empty at this point. Looks ok to me Regards, Sergei

1 0

[Maria-developers] Issue with index condition pushdown being used with no end_range set
by Zardosht Kasheff 12 Dec '13

12 Dec '13

Hello all, I've noticed a scenario with index condition pushdown (ICP) in MariaDB that leads to really bad performance in TokuDB. I don't know if it is a bug in ICP or if TokuDB is misusing/misunderstanding the API. Here is the problem. Suppose we run the following query on the following schema: SELECT * FROM foo WHERE col1 = '7' ORDER BY b desc | foo | CREATE TABLE `foo` ( `id` int(11) NOT NULL AUTO_INCREMENT, `col1` varchar(100) COLLATE utf8_unicode_ci NOT NULL, `b` int(11) DEFAULT NULL, `c` int(11) DEFAULT NULL, `d` int(11) DEFAULT NULL, PRIMARY KEY (`id`), CLUSTERING KEY `col1_2` (`col1`,`b`) ) ENGINE=TokuDB AUTO_INCREMENT=8001 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci ROW_FORMAT=TOKUDB_ZLIB | The output of explain is: MariaDB [test]> explain SELECT * FROM foo WHERE col1 = '7' ORDER BY b desc; +------+-------------+-------+------+---------------+--------+---------+-------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------+------+---------------+--------+---------+-------+------+-------------+ | 1 | SIMPLE | foo | ref | col1_2 | col1_2 | 302 | const | 1320 | Using where | +------+-------------+-------+------+---------------+--------+---------+-------+------+-------------+ 1 row in set (2.32 sec) The query is doing a reverse range scan, as it should. We get handler::idx_cond_push called, but end_range is not set. As a result, TokuDB thinks it can use index condition pushdown to filter rows. As we do this and get to the end, because end_range is not set, we never get a result of ICP_OUT_OF_RANGE, and always get a result of ICP_NO_MATCH. So, when we go to retrieve that first row past the end of the range, the row that will tell MySQL it should stop searching, TokuDB never finds a row and never gets ICP_NO_MATCH. It scans to the beginning of the index (because it is running in reverse order), getting ICP_NO_MATCH for every row it encounters. Although my index is clustering, I've seen this with a normal key as well. If col1 is an int instead of the funky varchar, handler::idx_cond_push is never called, so this problem does not exist. It seems to me that if end_range is not set and we cannot reliably learn when we go out of range, we should not have handler::idx_cond_push called, otherwise we can get bad performance such as the example above. Thoughts? Thanks --Zardosht

1 1

Re: [Maria-developers] [Commits] Rev 3916: MDEV-5403 - Reduce usage of LOCK_open: tc_count
by Sergei Golubchik 10 Dec '13

10 Dec '13

Hi, Sergey! Not a review, only a comment on TDC_atomic part: 1. This is perfectly generally useful, not TDC specific at all. I'd consider moving it to my_atomic.h under #ifdef __cplusplus 2. These are supposed to be trivial inlined functions. I don't think you should use inheritance and virtual methods here. Everything should be in the template. I understand that function names (add64/add32/etc) are a bit tricky. Two approaches: pass them as template parameters (like in template <typename T, ADD, CAS, ...>) or - perhaps, if you put this into my_atomic.h you'll be able to generate the necessary code without using my_atomic_add32/etc ? Regards, Sergei

2 1

Re: [Maria-developers] [svoj@mariadb.org: [Commits] Rev 3807: MDEV-4956 - Reduce usage of LOCK_open: TABLE_SHARE::tdc.used_tables in lp:maria/10.0]
by Sergei Golubchik 10 Dec '13

10 Dec '13

Hi, Sergey! Looks pretty much ok. See few comments/questions below. On Oct 24, Sergey Vojtovich wrote: > ------------------------------------------------------------ > revno: 3807 > revision-id: svoj(a)mariadb.org-20130827121233-xh1uyhgfwbhedqyf > parent: jplindst(a)mariadb.org-20130823060357-pww92qxla7o8iir7 > committer: Sergey Vojtovich <svoj(a)mariadb.org> > branch nick: 10.0 > timestamp: Tue 2013-08-27 16:12:33 +0400 > message: > MDEV-4956 - Reduce usage of LOCK_open: TABLE_SHARE::tdc.used_tables > > - tc_acquire_table and tc_release_table do not access > TABLE_SHARE::tdc.used_tables anymore ok > - in tc_acquire_table(): release LOCK_tdc after we relase LOCK_open > (saves a few CPU cycles in critical section) This is a bit counter-intuitive. Your change is to hold the lock more than necessary. Does it give a measurable performance improvement? > - in tc_release_table(): if we reached table cache threshold, evict > to-be-released table without moving it to unused_tables. unused_tables > must be empty at this point (added assertion). Why unused_tables must be empty at this point? > === modified file 'sql/sql_base.cc' > --- a/sql/sql_base.cc 2013-08-14 08:48:50 +0000 > +++ b/sql/sql_base.cc 2013-08-27 12:12:33 +0000 > @@ -370,7 +372,7 @@ void free_io_cache(TABLE *table) > > void kill_delayed_threads_for_table(TABLE_SHARE *share) > { > - TABLE_SHARE::TABLE_list::Iterator it(share->tdc.used_tables); > + TABLE_SHARE::All_share_tables_list::Iterator it(share->tdc.all_tables); In this function, I'd suggest to add some flag to be able to skip the mutex and the loop altogether - as in the absolute majority of cases there will be no delayed insert thread to kill. Either use a global flag to know if there's a delayed thread running, or create a per-share flag. > TABLE *tab; > Regards, Sergei

2 4