- developers - lists.mariadb.org

[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