- developers - lists.mariadb.org

[Maria-developers] MDEV-8372 Use helper methods introduced in MDEV-7824 all around the code
by Alexander Barkov 11 Sep '15

11 Sep '15

Hi Sergei, Please review my patch for mdev-8372. I found only a few places to reuse the new methods. Also, had to add some more helper methods to make the code clearer. Thanks.

2 3

Re: [Maria-developers] [Commits] 32b1497: MDEV-7990: ERROR 1526 when procedure executed for second time ALTER TABLE partition ... pMAX values less than MAXVALUE
by Sergei Golubchik 11 Sep '15

11 Sep '15

Hi, Sanja! On Aug 06, sanja(a)mariadb.com wrote: > revision-id: 32b14970a1b88571aa96f604e5c59ab6bf1b298c > parent(s): aa5095627e2619bdad7916d33d1016802a84a9e1 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-08-06 14:00:48 +0200 > message: > > MDEV-7990: ERROR 1526 when procedure executed for second time ALTER > TABLE partition ... pMAX values less than MAXVALUE > > Added cleaning partition data which are saved in LEX structure to make > possible correct re-execution of a SP or PS using the code. This seems to be wrong now. It's an old comment, but now your fix works differently, doesn't it? The patch is ok to push, thanks! Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 0a1b60a: MDEV-8450: PATCH] Wrong macro expansion in Query_cache::send_result_to_client()
by Sergey Vojtovich 06 Sep '15

06 Sep '15

Hi Sanja, ok to push, a few minor notes JFYI inline. I found only one real bug, but generally I agree that we should fix these fragile macros. On Tue, Sep 01, 2015 at 11:47:09AM +0200, sanja(a)mariadb.com wrote: > revision-id: 0a1b60a8aee4bce3235fd5a1d8cb2231b51ff5cc (mariadb-10.0.21-7-g0a1b60a) > parent(s): 4b41e3c7f33714186c97a6cc2e6d3bb93b050c61 > committer: Oleksandr Byelkin > timestamp: 2015-09-01 11:47:06 +0200 > message: > > MDEV-8450: PATCH] Wrong macro expansion in Query_cache::send_result_to_client() > > Expression in macro protected by () > > diff --git a/include/maria.h b/include/maria.h > index 16a9bea..cdaeade 100644 > --- a/include/maria.h > +++ b/include/maria.h > @@ -43,7 +43,7 @@ extern "C" { > #define MARIA_NAME_IEXT ".MAI" > #define MARIA_NAME_DEXT ".MAD" > /* Max extra space to use when sorting keys */ > -#define MARIA_MAX_TEMP_LENGTH 2*1024L*1024L*1024L > +#define MARIA_MAX_TEMP_LENGTH (2*1024L*1024L*1024L) > /* Possible values for maria_block_size (must be power of 2) */ > #define MARIA_KEY_BLOCK_LENGTH 8192 /* default key block length */ > #define MARIA_MIN_KEY_BLOCK_LENGTH 1024 /* Min key block length */ Was this used at all? May be remove it? > diff --git a/sql/log_slow.h b/sql/log_slow.h > index 2ae07da..3ae2060 100644 > --- a/sql/log_slow.h > +++ b/sql/log_slow.h > @@ -16,23 +16,23 @@ > /* Defining what to log to slow log */ > > #define LOG_SLOW_VERBOSITY_INIT 0 > -#define LOG_SLOW_VERBOSITY_INNODB 1 << 0 > -#define LOG_SLOW_VERBOSITY_QUERY_PLAN 1 << 1 > -#define LOG_SLOW_VERBOSITY_EXPLAIN 1 << 2 > +#define LOG_SLOW_VERBOSITY_INNODB (1 << 0) Was LOG_SLOW_VERBOSITY_INNODB used at all? May be remove it? > +#define LOG_SLOW_VERBOSITY_QUERY_PLAN (1 << 1) > +#define LOG_SLOW_VERBOSITY_EXPLAIN (1 << 2) > > #define QPLAN_INIT QPLAN_QC_NO > > -#define QPLAN_ADMIN 1 << 0 > -#define QPLAN_FILESORT 1 << 1 > -#define QPLAN_FILESORT_DISK 1 << 2 > -#define QPLAN_FULL_JOIN 1 << 3 > -#define QPLAN_FULL_SCAN 1 << 4 > -#define QPLAN_QC 1 << 5 > -#define QPLAN_QC_NO 1 << 6 > -#define QPLAN_TMP_DISK 1 << 7 > -#define QPLAN_TMP_TABLE 1 << 8 > -#define QPLAN_FILESORT_PRIORITY_QUEUE 1 << 9 > +#define QPLAN_ADMIN (1 << 0) > +#define QPLAN_FILESORT (1 << 1) > +#define QPLAN_FILESORT_DISK (1 << 2) > +#define QPLAN_FULL_JOIN (1 << 3) > +#define QPLAN_FULL_SCAN (1 << 4) > +#define QPLAN_QC (1 << 5) > +#define QPLAN_QC_NO (1 << 6) > +#define QPLAN_TMP_DISK (1 << 7) > +#define QPLAN_TMP_TABLE (1 << 8) > +#define QPLAN_FILESORT_PRIORITY_QUEUE (1 << 9) > > /* ... */ > -#define QPLAN_MAX ((ulong) 1) << 31 /* reserved as placeholder */ > +#define QPLAN_MAX (((ulong) 1) << 31) /* reserved as placeholder */ > log_slow.h was fixed in rev.203f4d419 in my 10.0. Did you use outdated tree? I may be wrong, but there seem to be no real bug with QPLAN_QC_NO currently. Just because nobody sets it. So in fact it clears QPLAN_ADMIN, which FWICS is never set at this point. But it is a good to have it fixed nevertheless. Btw, QPLAN_QC_NO doesn't seem to be used in fact. May be remove it? > diff --git a/storage/archive/archive_test.c b/storage/archive/archive_test.c > index d01c1e0..bb052b8 100644 > --- a/storage/archive/archive_test.c > +++ b/storage/archive/archive_test.c > @@ -33,7 +33,7 @@ > > #define ARCHIVE_ROW_HEADER_SIZE 4 > > -#define BUFFER_LEN 1024 + ARCHIVE_ROW_HEADER_SIZE > +#define BUFFER_LEN (1024 + ARCHIVE_ROW_HEADER_SIZE) > > char test_string[BUFFER_LEN]; Alright, there was a bug in this line: assert(write_length != count * BUFFER_LEN); > diff --git a/strings/ctype.c b/strings/ctype.c > index 048fbe3..d8a1dd7 100644 > --- a/strings/ctype.c > +++ b/strings/ctype.c > @@ -264,7 +264,7 @@ static const struct my_cs_file_section_st > } > > #define MY_CS_CSDESCR_SIZE 64 > -#define MY_CS_TAILORING_SIZE 32*1024 > +#define MY_CS_TAILORING_SIZE (32*1024) > #define MY_CS_UCA_VERSION_SIZE 64 > #define MY_CS_CONTEXT_SIZE 64 Was this used at all? May be remove it? Regards, Sergey

2 1

Re: [Maria-developers] [Commits] 62fe87c: MDEV-8663: IF Statement returns multiple values erroneously (or Assertion `!null_value' failed in Item::send(Protocol*, String*))
by Alexander Barkov 04 Sep '15

04 Sep '15

Hi Sanja, From my understanding, the patch fixes consequences of the problem, but not the problem itself. It very likely will still have crashes with slightly modified SQL scripts. The source of the problem is that Item_func_hybrid_result_type::val_decimal() does not return NULL when int_op() or real_op() set null_value to "true". By the way, compare Item_func_hybrid_result_type::val_decimal() with a very similar method Item_func_hybrid_result_type::val_str(). The latter already handle the INT_RESULT and REAL_RESULT cases well and return NULL properly in case of null_value. get_date(), val_int(), val_real() also look fine for me. So the are problems only in val_decimal(). I propose a small patch that fixes the source of the problem. This is the small patch: > @@ -1038,17 +1026,21 @@ my_decimal *Item_func_hybrid_result_type::val_decimal(my_decimal *decimal_value) > case INT_RESULT: > { > longlong result= int_op(); > + if (null_value) > + return NULL; > int2my_decimal(E_DEC_FATAL_ERROR, result, unsigned_flag, decimal_value); > break; > } > case REAL_RESULT: > { > double result= (double)real_op(); > + if (null_value) > + return NULL; > double2my_decimal(E_DEC_FATAL_ERROR, result, decimal_value); > break; > } I also propose an extended patch version, to cover the code with more DBUG_ASSERTs, so in case of the null_value related bugs it crashes much earlier than in Item::send(). It will be easier to debug problems this way. To avoid much code duplication, I added three private helper methods. The extended version of the patch is attached. The scripts from the bug report start to return expected results, with no crashes in DEBUG build, and "mtr --suite=main" works fine. I have not run the entire mtr though, to save time. Greetings. On 09/03/2015 08:00 PM, sanja(a)mariadb.com wrote: > revision-id: 62fe87c5a239c7304b245ce5954c87aecb6382ad (mariadb-5.5.45-1-g62fe87c) > parent(s): fa51f70dc68fe2f3afe943e2c81fcbdb34f16cad > committer: Oleksandr Byelkin > timestamp: 2015-09-03 18:00:43 +0200 > message: > > MDEV-8663: IF Statement returns multiple values erroneously (or Assertion `!null_value' failed in Item::send(Protocol*, String*)) > > keeping contract: NULL value mean NULL pointer in val_str and val_deciman. > > --- > mysql-test/r/func_if.result | 17 +++++++++++++++++ > mysql-test/t/func_if.test | 14 ++++++++++++++ > sql/item_cmpfunc.cc | 6 ++++-- > sql/item_func.cc | 5 +++++ > 4 files changed, 40 insertions(+), 2 deletions(-) > > diff --git a/mysql-test/r/func_if.result b/mysql-test/r/func_if.result > index c7f548a..61f63cc 100644 > --- a/mysql-test/r/func_if.result > +++ b/mysql-test/r/func_if.result > @@ -234,3 +234,20 @@ SELECT if(1, NULL, (SELECT min('hello'))); > if(1, NULL, (SELECT min('hello'))) > NULL > End of 5.2 tests > +# > +# MDEV-8663: IF Statement returns multiple values erroneously > +# (or Assertion `!null_value' failed in Item::send(Protocol*, String*) > +# > +CREATE TABLE `t1` ( > +`datas` VARCHAR(25) NOT NULL > +) ENGINE=InnoDB DEFAULT CHARSET=utf8; > +Warnings: > +Warning 1286 Unknown storage engine 'InnoDB' > +Warning 1266 Using storage engine MyISAM for table 't1' > +INSERT INTO `t1` VALUES ('1,2'), ('2,3'), ('3,4'); > +SELECT IF(FIND_IN_SET('1', `datas`), 1.5, IF(FIND_IN_SET('2', `datas`), 2, NULL)) AS `First`, '1' AS `Second`, '2' AS `Third` FROM `t1`; > +First Second Third > +1.5 1 2 > +2.0 1 2 > +NULL 1 2 > +drop table t1; > diff --git a/mysql-test/t/func_if.test b/mysql-test/t/func_if.test > index 2b89a61..8fdba77 100644 > --- a/mysql-test/t/func_if.test > +++ b/mysql-test/t/func_if.test > @@ -206,6 +206,20 @@ SELECT if(1, NULL, (SELECT min('hello'))); > > --echo End of 5.2 tests > > +--echo # > +--echo # MDEV-8663: IF Statement returns multiple values erroneously > +--echo # (or Assertion `!null_value' failed in Item::send(Protocol*, String*) > +--echo # > +CREATE TABLE `t1` ( > +`datas` VARCHAR(25) NOT NULL > +) ENGINE=InnoDB DEFAULT CHARSET=utf8; > + > +INSERT INTO `t1` VALUES ('1,2'), ('2,3'), ('3,4'); > + > +SELECT IF(FIND_IN_SET('1', `datas`), 1.5, IF(FIND_IN_SET('2', `datas`), 2, NULL)) AS `First`, '1' AS `Second`, '2' AS `Third` FROM `t1`; > + > +drop table t1; > + > --disable_query_log > # Restore timezone to default > set time_zone= @@global.time_zone; > diff --git a/sql/item_cmpfunc.cc b/sql/item_cmpfunc.cc > index 998cb1c..4f07318 100644 > --- a/sql/item_cmpfunc.cc > +++ b/sql/item_cmpfunc.cc > @@ -2692,7 +2692,8 @@ Item_func_if::str_op(String *str) > String *res=arg->val_str(str); > if (res) > res->set_charset(collation.collation); > - null_value=arg->null_value; > + if (null_value=arg->null_value) > + res= NULL; > return res; > } > > @@ -2703,7 +2704,8 @@ Item_func_if::decimal_op(my_decimal *decimal_value) > DBUG_ASSERT(fixed == 1); > Item *arg= args[0]->val_bool() ? args[1] : args[2]; > my_decimal *value= arg->val_decimal(decimal_value); > - null_value= arg->null_value; > + if (null_value= arg->null_value) > + value= NULL; > return value; > } > > diff --git a/sql/item_func.cc b/sql/item_func.cc > index 2f51308..cbb8aa0 100644 > --- a/sql/item_func.cc > +++ b/sql/item_func.cc > @@ -924,6 +924,7 @@ String *Item_func_hybrid_result_type::val_str(String *str) > ltime.time_type= mysql_type_to_time_type(field_type()); > str->length(my_TIME_to_str(&ltime, const_cast<char*>(str->ptr()), decimals)); > str->set_charset(&my_charset_bin); > + DBUG_ASSERT(!null_value); > return str; > } > return str_op(&str_value); > @@ -932,6 +933,7 @@ String *Item_func_hybrid_result_type::val_str(String *str) > case IMPOSSIBLE_RESULT: > DBUG_ASSERT(0); > } > + DBUG_ASSERT(!null_value || (str == NULL)); > return str; > } > > @@ -1071,7 +1073,10 @@ my_decimal *Item_func_hybrid_result_type::val_decimal(my_decimal *decimal_value) > } > String *res; > if (!(res= str_op(&str_value))) > + { > + null_value= 1; > return NULL; > + } > > str2my_decimal(E_DEC_FATAL_ERROR, (char*) res->ptr(), > res->length(), res->charset(), decimal_value); > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits >

1 0

[Maria-developers] [GSoC] MDEV-4674 Port InnoDB memcached interface to MariaDB - Merging the code
by Piotr Jurkiewicz 02 Sep '15

02 Sep '15

Hi again, there are some issues which I think needs to be resolved before merging the code. 1. Bundle libevent or not? Memcached daemon is built with the help of libevent library. MySQL decided to bundle this library inside its sources, in 'libevent' top level directory. This allows to compile and run the plugin on machines without installed system-wide libevent library. The bundled libevent is used by default during the compilation of plugin. Optionally, it can be specified in CMake variable to use system-wide libevent instead. It needs to be decided whether MariaDB should bundle libevent as well inside its sources. Possible outcomes: a) Leave bundled libevent as is, in the 'libevent' top level directory. b) Move bundled libevent into the 'daemon_memcached' plugin directory, in order to not clutter the top level directory. c) Remove bundled libevent. After that, system libevent headers will become compile-time dependency and system libevent shared library runtime dependency of the plugin. 2. How to transfer InnoDB API callback array pointer to the plugin? InnoDB Memcached interface engine needs to obtain the pointer to InnoDB API callback array in some way. MySQL originally implemented that in 'sql/sql_plugin.cc:plugin_initialize()' in the following way: https://github.com/piotrjurkiewicz/mariadb-server/commit/4eb8fd9c211f396694… As you can see, this is not a clean solution. Possible outcomes: a) Leave the MySQL's solution as is. b) Figure out a better way to transfer the pointer. 3. Where should I post the documentation? 4. How should I prepare the pull request? Should I rebase my branch on the top of current branch before that? I looking forward for your suggestions and decisions. Piotr

2 1

Re: [Maria-developers] MDEV-8389 patch review (part#1)
by Sergey Petrunia 28 Aug '15

28 Aug '15

Hi Diwas, On Thu, Aug 27, 2015 at 09:23:55PM +0530, Diwas Joshi wrote: > hello sergei, I am attaching two patches with this mail. > MDEV-8389_first is the original patch with mysql_create_table() method used > to create tables. I have fixed the crash that was occurring with queries > like select name from f21('aaa') where name like '%foo%'; So, this patch is > giving the results. > MDEV-8389_second contains use of create_tmp_table() so far the table is > being created, but the queries can't see it so it is still giving errors > like table not present. I guess we'll have to fix the Name Resolution for > queries to be able to use the created table. > > Also both patches have fix for MDEV-8650. I've looked at the patch. Unfortunately, it gives little confidence that it will work in all cases. There are a lot of weird things. To name a few: > + tmp_table_param->schema_table = 1; why? ... > + switch (field->sql_type) > + { > + case MYSQL_TYPE_VARCHAR: > + case MYSQL_TYPE_VAR_STRING: > + case MYSQL_TYPE_STRING: > + case MYSQL_TYPE_SET: > + field->pack_flag= 0; > + break; ... This big switch statement is copied from Create_field::init_for_tmp_table. Why is it copied (and not factored out?) If there is a need to copy the code from that function into here, why do you not also copy this part: pack_flag|= (maybe_null ? FIELDFLAG_MAYBE_NULL : 0) | (is_unsigned ? 0 : FIELDFLAG_DECIMAL); > + TABLE *vtable= create_virtual_tmp_table(thd, sp->m_cols_list); ... > + if (! (table = create_tmp_table(thd, tmp_table_param, *types, > + (ORDER*) 0, 1, 1, > + TMP_TABLE_ALL_COLUMNS, HA_POS_ERROR, > + sp->m_table_alias.str))) why create_virtual_tmp_table and then create_tmp_table? 'vtable' is created and then not freed. I look at the comment near create_virtual_tmp_table() definition and see: The table is created in THD mem_root, so are the table's fields. Consequently, if you don't BLOB fields, you don't need to free it. But what if the table does have blob fields? > + table->file->extra(HA_EXTRA_IGNORE_DUP_KEY); What's this? I grep for HA_EXTRA_IGNORE_DUP_KEY and find this explanation: HA_EXTRA_IGNORE_DUP_KEY: HA_EXTRA_NO_IGNORE_DUP_KEY: Informs the handler to we will not stop the transaction if we get an duplicate key errors during insert/upate. Do we expect to get duplicate key errors when inserting into the table? > +bool execute_table_function(THD *thd, sp_head *sp, List<Item> *value_list) > +{ > + /* > + We never write CALL statements into binlog: > + - If the mode is non-prelocked, each statement will be logged > + separately. > + - If the mode is prelocked, the invoking statement will care > + about writing into binlog. > + So just execute the statement. How is CALL statement relevant to executing a table function? I think at this point it is clear that this patch needs more work before it can be pushed. BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] MDEV-8389 patch review (part#1)
by Sergey Petrunia 27 Aug '15

27 Aug '15

On Sat, Aug 22, 2015 at 02:10:58AM +0530, Diwas Joshi wrote: > Hello Sergei, sorry for late reply, i was busy finishing my office > work yesterday. Please find some of my doubts below (I would come on > irc to discuss but I am travelling today and will be working overnight > in the train, I hope to be on irc tomorrow). > > Regarding use of storage engine-- If one uses SET > default_tmp_storage_engine, to set the default storage engine for > temporary tables in the current session, it is using that default > storage engine. In my function I have used > create_info.use_default_db_type(thd) which does the work. > (Referencing https://dev.mysql.com/doc/refman/5.6/en/storage-engine-setting.html) > > Regarding the name resolution error. I didn't know it but if there is > already a table present in the database with same name, temporary > table is still being created and used int the function. so that is one > problem solved. For the problem of a function being used multiple > times in a query, I was just curious as how would we solve it if we > switch to create_tmp_table(). As I mentioned before, the solution should be: >> - Patch the name resolution code so that the statements inside a Table Function >> see the return table of that Table Function. "Name resolution" is a process of finding which table should be used when a query refers to table named TBL. The process currently is: 1. Look at user-created temporary tables with name TBL. 2. If none found, look at the regular database tables in the current database with the name TBL. Our problem is that tables created with mysql_create_table() are visible to step#1, and all parts of the query can see them. This includes those parts of the query that we don't want to see the table: other stored procedures, the query that invokes the table function, etc. Temporary tables that are created with create_tmp_table() are not visible to step #1. We will not have the problem of temporary table being visible where it should not be visible. We will have the problem though, that temporary table must be visible where it needs to be visible. This is achieved by modifying step#1 in Name Resolution code to also look at the name of the returned table when we are in a table function. > Still looking into crash because of select name from f21('aaa') where > name like '%foo%' and errors MDEV-8649 and MDEV-8650; > Other errors in the patch have been fixed. > BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] MDEV-8643 Valgrind error in mroonga/storage.index_multiple_column_unique_datetime_index_read
by Alexander Barkov 27 Aug '15

27 Aug '15

Hi Kentoku and Kouhei, FYI, I just filed this bug report: https://mariadb.atlassian.net/browse/MDEV-8643 Can you please have a look into this? Thanks!

1 1

[Maria-developers] New Hacker
by Aniket Shukla 27 Aug '15

27 Aug '15

Hey MariaDB team,this is Aniket.I'm a final year undegraduate student and would like to contribute to MariaDB.Since this is my first open source project, I have no idea where to begin.I have good knowledge of python,c++ and have benn using MySQL for my previous projects. Any help would be welcomed.

2 1

[Maria-developers] [GSoC] MDEV-4674 Port InnoDB memcached interface to MariaDB - Final report
by Piotr Jurkiewicz 25 Aug '15

25 Aug '15

Hi all, as the pencils down date has passed, I am posting a report on what I have during the whole project. Repository of my project is available here: https://github.com/piotrjurkiewicz/mariadb-server/commits/10.1-memcached Some stats: 33 commits before the midterm 60 commits after the midterm 93 commits total What have been done in details: =============================== BEFORE MIDTERM: --------------- 1. Code of InnoDB Memcached plugin has been imported from MySQL into the MariaDB tree. 2. There were some differences between MariaDB and MySQL, which blocked the plugin from out-of-the-box compilation and correct operation. They have been resolved. 3. Test suite for the plugin has been imported from MySQL. Compatibility changes were introduced into these test cases which required them. The test suite was modified to assign memcached port number dynamically from mtr worker's pool, what allows to run the same test in parallel for many combinations. The plugin fully passes the test suite, both for 'innodb_plugin' and 'xtradb' combinations. 4. Some enhancements and bug fixes have been introduced into the plugin: - detection of memcached daemon initialization has been fixed -- this eliminated unnecessary wait (15 seconds) on plugin shutdown and memory leak (in cases when plugin failed to initialize properly before) - memcached arithmetic commands (incr/decr) handling has been improved -- now numeric columns values are handled in a consistent and predictable way - incorrect handling of unsigned not null integers columns has been fixed AFTER MIDTERM: -------------- 5. Memcached daemon code has been updated to the latest version from upstream memcached/engine-pu branch. 6. Plugin architecture has been changed to "one table per socket", as originally proposed in MDEV-4674 bug report. This allows usage of well known security solutions (firewalls, unix file permissions) to restrict access to different tables for different users. Now user can specify which tables should be accessible on which sockets. Memcached daemon will listen on all these sockets and execute commands on appropriate table, depending on which socket client connected. Supported protocols are TCP, UDP and UNIX stream sockets. Sockets are configured in 'daemon_memcached/containers' table: INSERT INTO containers VALUES ("tcp://*:11211", "db0", "table0", "key_col", "val_col", "c3", "c4", "c5", "PRIMARY", "|"); INSERT INTO containers VALUES ("udp://localhost:11222", "db0", "table1", "key_col", "val_col", "c3", "c4", "c5", "PRIMARY", "|"); INSERT INTO containers VALUES ("unix:/tmp/mc.sock", "db1", "table0", "key_col", "val_col", "c3", "c4", "c5", "PRIMARY", "|"); 7. Plugin has been decoupled from InnoDB. Now plugin is split into two parts: - generic 'daemon_memcached.so' - InnoDB specific 'daemon_memcached_engine_ib.so' The first library is a MariaDB plugin, which should be installed with command: install plugin daemon_memcached soname "daemon_memcached.so"; This library is generic. It provides Memcached protocol handling and it loads the second library, which is API-specific engine for accessing the database. Which engine library should be loaded can be specified in 'daemon_memcached_engine_lib_name' MariaDB server option. Now, the only existing engine library is daemon_memcached_engine_ib.so, which utilizes InnoDB API to access the data. It can operate on InnoDB and XtraDB tables. 8. Some enhancements and bug fixes have been introduced into the plugin: - CMake options and #cmakedefines associated with the plugin have been cleaned up - embedded default Memcached engine has been removed - duplicated code in Memcached source has been removed - fixed MySQL-originating bug with flush_all of non default table -- command flush_all always flushed the default table, not the current one - removed support for in-connection table switching -- after introduction of one table/port architecture it was redundant - plugin shutdown time has been improved -- from constant time of 2 seconds to average time of 0.5 second - logging of plugin has been refactored -- now plugin send log messages to MariaDB log instead of stderr - fixed Memcached-originating bug with get_thread_stats() -- bug resulted in out of bound array accesses and writes, what leaded to SEGFAULT - fixed MySQL-originating crash during 'flush_all' memcached command bug -- crash happened when table was heavily loaded with DML operations and because of that ib_cb_cursor_set_lock() failed to obtain a lock on the table, returning DB_LOCK_WAIT_TIMEOUT error - fixed MySQL-originating multiple memcached_sync_count for the same transaction bug -- the memcached_sync_count was incremented multiple times for the same transaction and after the end of transaction, it was not reset to zero, what blocked TRUNCATE command on any InnoDB table, on which Memcached had operated during program lifetime, even after uninstalling the plugin - support for numeric values has been finished -- now BIGINT overflows in the same way as smaller types, test to check over/under-flowing of all integer types has been added For details of all changes please see commit messages associated with them: https://github.com/piotrjurkiewicz/mariadb-server/commits/10.1-memcached ----------------------------------------------------------------------- Moreover, I planned to implement a new interface inside the Memcached plugin, which will use Handler API for database access. This would make possible to use the plugin to access databases based on storage engines other than InnoDB/XtraDB. However, during testing I discovered many serious bugs, either in Memcached or InnoDB API engine, which originated from upstream Memcached or MySQL and resulted in crashes or deadlocks. I decided that first I should fix them before implementing new functionalities. I lost a lot of time on investigating these bugs and I was unable to finish the implementation of Handler API engine. Nevertheless, I think the whole plugin is ready to be merged into MariaDB. All user-facing changes (like one port/table architecture) have been completed. Eventual later introduction of Handler API engine will not be associated with any user-facing compatibility changes. It will just lift the requirement that all databases accessed via the Memcached plugin must be InnoDB/XtraDB. Now I am going to write a separate email to coordinate the merge of my code into MariaDB repository. Piotr

1 0