- developers - lists.mariadb.org

[Maria-developers] [Patch] Fix to mysql.server init script
by Alangi Derick 21 Aug '15

21 Aug '15

This is a fix to the bug in the mysql.server init script which uses a wrong server name (MySQL) instead of MariaDB. It is not fixed and this is the patch below. Regards Alangi Derick Ndimnain

1 0

[Maria-developers] Please review: MDEV-8433 Make field<'broken-string' use indexes
by Alexander Barkov 20 Aug '15

20 Aug '15

Hi Sergei, Please review my patch for MDEV-8433. I had doubts about one detail: how to make Field::store() that we're currently creating a value for range search rather than regular doing a INSERT/UPDATE. I could think of two options: 1. Using sql_mode, similar to how temporal types pass MODE_INVALID_DATES. 2. Using a new parameter to this method: int Field::store(const char *str, uint length, CHARSET_INFO *cs); The former needed less changes, so I chose to use sql_mode. But probably N2 would be better. Please suggest. Thanks.

1 0

Re: [Maria-developers] [JIRA] (MDEV-7063) Split String into logical components
by Alexander Barkov 20 Aug '15

20 Aug '15

Hi Rasmus, I noticed you put this task on Sprint 10.1.7-2. Did I miss some discussion about this? From my understanding, Sergei and Monty were not enthusiastic about this task (but I still think it should be helpful). Thanks. On 08/19/2015 06:26 PM, Rasmus Johansson (JIRA) wrote: > > [ https://mariadb.atlassian.net/browse/MDEV-7063?page=com.atlassian.jira.plug… ] > > Rasmus Johansson updated MDEV-7063: > ----------------------------------- > Sprint: 10.1.7-2 > >> Split String into logical components >> ------------------------------------ >> >> Key: MDEV-7063 >> URL: https://mariadb.atlassian.net/browse/MDEV-7063 >> Project: MariaDB Server >> Issue Type: Task >> Reporter: Alexander Barkov >> Assignee: Michael Widenius >> Fix For: 10.1 >> >> >> The string class currently consists of the following components: >> - memory allocation routines (using mysys) >> - binary string routines >> - character set aware routines. >> Storage engines (e.g. ConnectSE) often need String-alike classes, but cannot use the current String implementation because of their own memory management system. So they have to reimplement the same set of functionality, but with their own memory managers. This is bug prone and makes duplicate code. >> Also, in some cases it is useful to have character-set unaware strings (just array of bytes), and static strings without allocation. >> This task is to split String into logical pieces: >> 1. class Static_binary_string >> 2. class Charset >> 3. class Static_character_string (#1 + #2) >> 4. class Memory_mysys >> 5. template<typename MEM> class String_with_alloc >> 6. class String (#3 + #5) >> ConnectSE will use #5 (templace class String_with_alloc), in combination with their own memory allocator. > > > > -- > This message was sent by Atlassian JIRA > (v7.0.0-OD-01-193#70101) >

1 0

Re: [Maria-developers] MDEV-8389 patch review
by Sergey Petrunia 19 Aug '15

19 Aug '15

Also, I'm getting a crash when trying to debug a slightly complex example: delimiter | CREATE FUNCTION f10(param1 VARCHAR(11)) RETURNS TABLE return_table(name VARCHAR(11)) deterministic BEGIN insert into return_table values('foo'); END| DELIMITER ; select name from f21('aaa') where name like '%foo%'; Causes a crash: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff7efa700 (LWP 5142)] 0x0000555555cb6000 in Item_field::fix_fields (this=0x7fff80006db8, thd=0x555558161ca0, reference=0x7fff80007070) at /home/psergey/dev-git/10.1-gsoc-repo/sql/item.cc:4928 (gdb) wher #0 0x0000555555cb6000 in Item_field::fix_fields (this=0x7fff80006db8, thd=0x555558161ca0, reference=0x7fff80007070) at /home/psergey/dev-git/10.1-gsoc-repo/sql/item.cc:4928 #1 0x0000555555cf86e8 in Item_func::fix_fields (this=0x7fff80006fe0, thd=0x555558161ca0, ref=0x7fff8000b060) at /home/psergey/dev-git/10.1-gsoc-repo/sql/item_func.cc:208 #2 0x0000555555cd9747 in Item_func_like::fix_fields (this=0x7fff80006fe0, thd=0x555558161ca0, ref=0x7fff8000b060) at /home/psergey/dev-git/10.1-gsoc-repo/sql/item_cmpfunc.cc:4856 #3 0x00005555559ff1b0 in setup_conds (thd=0x555558161ca0, tables=0x7fff80006780, leaves=..., conds=0x7fff8000b060) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_base.cc:8657 #4 0x0000555555aeb4f7 in setup_without_group (thd=0x555558161ca0, ref_pointer_array=0x7fff8000b198, tables=0x7fff80006780, leaves=..., fields=..., all_fields=..., conds=0x7fff8000b060, order=0x0, group=0x0, hidden_group_fields=0x7fff8000af40, reserved=0x555558165ffc) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_select.cc:631 #5 0x0000555555aa6d99 in JOIN::prepare (this=0x7fff8000ac48, rref_pointer_array=0x555558165fd8, tables_init=0x7fff80006780, wild_num=0, conds_init=0x7fff80006fe0, og_num=0, order_init=0x0, skip_order_by=false, group_init=0x0, having_init=0x0, proc_param_init=0x0, select_lex_arg=0x555558165d60, unit_arg=0x555558165660) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_select.cc:786 #6 0x0000555555aafcab in mysql_select (thd=0x555558161ca0, rref_pointer_array=0x555558165fd8, tables=0x7fff80006780, wild_num=0, fields=..., conds=0x7fff80006fe0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fff8000ac28, unit=0x555558165660, select_lex=0x555558165d60) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_select.cc:3301 #7 0x0000555555aa5fd7 in handle_select (thd=0x555558161ca0, lex=0x555558165598, result=0x7fff8000ac28, setup_tables_done_option=0) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_select.cc:371 #8 0x0000555555a65fbf in execute_sqlcom_select (thd=0x555558161ca0, all_tables=0x7fff80006780) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_parse.cc:5799 #9 0x0000555555a5c25f in mysql_execute_command (thd=0x555558161ca0) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_parse.cc:2939 #10 0x0000555555a69554 in mysql_parse (thd=0x555558161ca0, rawbuf=0x7fff800064a8 "select name from f21('aaa') where name like '%foo%'", length=51, parser_state=0x7ffff7ef90f0) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_parse.cc:7175 #11 0x0000555555a584a7 in dispatch_command (command=COM_QUERY, thd=0x555558161ca0, packet=0x555558168ef1 "select name from f21('aaa') where name like '%foo%'", packet_length=51) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_parse.cc:1470 #12 0x0000555555a571c1 in do_command (thd=0x555558161ca0) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_parse.cc:1093 #13 0x0000555555b95b3d in do_handle_one_connection (thd_arg=0x555558161ca0) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_connect.cc:1347 #14 0x0000555555b95882 in handle_one_connection (arg=0x555558161ca0) at /home/psergey/dev-git/10.1-gsoc-repo/sql/sql_connect.cc:1258 #15 0x00007ffff691de9a in start_thread (arg=0x7ffff7efa700) at pthread_create.c:308 #16 0x00007ffff604e3fd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #17 0x0000000000000000 in ?? () (gdb) I am nut sure about the cause of this. It needs to be investigated. 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
by Sergey Petrunia 19 Aug '15

19 Aug '15

On Wed, Aug 12, 2015 at 01:58:40AM +0530, Diwas Joshi wrote: > hello sergei, > After I mailed you the last patch, I kept working further. I guess the code > has come to a point where it is giving some results. So, I did the > following things: > Earlier we were storing all the parameters in a select query inside > lex->value_list, but since there can be multiple functions in a query, I > declared a list for parameters inside table_list so we can store params > corresponding to each table function in it. Good. > Then instead of function name i created a table with table alias defined in > the function and change the table name to table alias inside select query > as well. This makes it possible for the queries inside the function > definition to access the temporary table we created. There is a problem > with this approach that there might already be a table present in the > database with that name, I am still thinking of a solution for it but we > can discuss a solution for it later. Yes, you're right. There is a problem here. It is not limited to the already existing tables with the same name. Let's work with this example: delimiter | CREATE FUNCTION f10(param1 VARCHAR(11)) RETURNS TABLE return_table(name VARCHAR(11)) deterministic BEGIN insert into return_table values('foo'); END| DELIMITER ; MariaDB [test]> select name from f10('aaa'); +------+ | name | +------+ | foo | +------+ 1 row in set (0.29 sec) Good. However, attempts to invoke the same function multiple times fail: MariaDB [test]> select name from f10('aaa') as TBL1 , f10('bbb') as TBL2; ERROR 1050 (42S01): Table 'return_table' already exists Your code uses this approach: 1. Create a temporary table in a manner similar to how user-specified CREATE TEMPORARY TABLE works. 2. Rely on regular MySQL's name resolution process to "see" the temporary table. The properties of this solution are: - If a temporary table has the same name as a regular db table, temporary table will "shadow" the regular table (this is ok). - user-created temporary tables are per-thread. Other threads do not see the temp. table (good). However, everything that executes within the thread will see the temp. table. For example, if a query calls two Table Functions, they will both see each others return tables. This is a problem. I think, a better approach would be: - switch to something like create_tmp_table() for creation of temporary tables. Tables that are created this way are normally not visible to the name resolution code. - Patch the name resolution code so that the statements inside a Table Function see the return table of that Table Function. 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
by Sergey Petrunia 19 Aug '15

19 Aug '15

Hi Diwas, While playing around, I've found and filed: https://mariadb.atlassian.net/browse/MDEV-8649 https://mariadb.atlassian.net/browse/MDEV-8650 I've filed these separately because I think they are not related to MDEV-8389. 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 19 Aug '15

19 Aug '15

Hi Diwas, Please find part #1 of the review below. I'll provide more soon. > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index 2998972..a9dc162 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -2466,6 +2466,8 @@ static bool do_execute_sp(THD *thd, sp_head *sp) > lex->first_lists_tables_same(); > /* should be assigned after making first tables same */ > all_tables= lex->query_tables; > + > + check_and_process_table_functions(thd, all_tables); > /* set context for commands which do not use setup_tables */ > select_lex-> > context.resolve_in_table_list_only(select_lex-> > @@ -5581,6 +5583,7 @@ static bool do_execute_sp(THD *thd, sp_head *sp) > } > THD_STAGE_INFO(thd, stage_query_end); > thd->update_stats(); > + //clear_table_functions(thd, all_tables); Please remove the comment. > > goto finish; > > @@ -5697,7 +5700,7 @@ static bool do_execute_sp(THD *thd, sp_head *sp) > thd->mdl_context.release_transactional_locks(); > } > #endif /* WITH_WSREP */ > - > + clear_table_functions(thd, all_tables); > DBUG_RETURN(res || thd->is_error()); > } > > @@ -5709,7 +5712,7 @@ static bool execute_sqlcom_select(THD *thd, TABLE_LIST *all_tables) > bool res; > /* assign global limit variable if limit is not given */ > { > - SELECT_LEX *param= lex->unit.global_parameters(); > + SELECT_LEX *param= lex->unit.global_parameters(); No need for this dummy change. > if (!param->explicit_limit) > param->select_limit= > new (thd->mem_root) Item_int((ulonglong) thd->variables.select_limit); > @@ -9222,3 +9225,182 @@ CHARSET_INFO *find_bin_collation(CHARSET_INFO *cs) > } > return cs; > } > + > +/* > + @brief > + Check for table functions and create corresponding tables to be used in query. > + > + @param thd Thread handle > + @param table_list A list of tables being processed in the query. > + > + @return > + False on success > + @retval > + TRUE on error > +*/ > +bool check_and_process_table_functions(THD *thd, TABLE_LIST *table_list) > +{ > + TABLE_LIST *tables = table_list; > + int err= 0; > + while(tables) > + { > + if (!tables->is_table_function || tables->table_name == NULL) > + { > + tables = tables->next_local; > + continue; > + } > + sp_head *sp; > + sp_name *name; > + LEX_STRING lex_db; > + LEX_STRING lex_name; > + lex_db.length= strlen(tables->db); > + lex_name.length= strlen(tables->table_name); > + lex_db.str= thd->strmake(tables->db, lex_db.length); > + lex_name.str= thd->strmake(tables->table_name, lex_name.length); > + name= new sp_name(lex_db, lex_name, true); > + name->init_qname(thd); > + int err=0; Please switch err from int to bool. > + > + if (!err && (sp = sp_find_routine(thd,TYPE_ENUM_FUNCTION, name, Why assign 'err' and then immediately check it? The code looks redundant. > + &thd->sp_proc_cache, FALSE))) //check if the table is a table-valued function. Please move the comment a few lines down, where the check is actually done. > + { > + if (sp->m_type == TYPE_ENUM_FUNCTION) > + my_error(ER_SP_TABLE_VALUE_EXPECTED, MYF(0)); > + LEX *old_lex= thd->lex, newlex; > + thd->lex= &newlex; > + lex_start(thd); > + ulonglong saved_mode= thd->variables.sql_mode; > + Table_specification_st create_info; > + Alter_info alter_info; > + create_info.init(); > + alter_info.reset(); > + create_info.default_table_charset= NULL; > + TABLE_LIST *create_table; > + create_info.options|= HA_LEX_CREATE_TMP_TABLE; > + LEX_STRING tablename,dbname; > + if (strlen(sp->m_table_alias.str) > 0) { > + tablename.str= sp->m_table_alias.str; > + tablename.length= strlen(sp->m_table_alias.str); > + } sp->m_table_alias is the alias of the return table of the table function. When can it have zero length? Please add a comment about this here, and also add a testcase in the .test file > + else { > + tablename.str= tables->table_name; > + tablename.length= strlen(tables->table_name); > + } > + dbname.str= tables->db; > + dbname.length= strlen(tables->db); > + Table_ident *new_ident= new Table_ident(thd, dbname, tablename, 0); > + if (!thd->lex->select_lex.add_table_to_list(thd, new_ident, NULL, > + TL_OPTION_UPDATING, > + TL_WRITE, MDL_EXCLUSIVE)) > + err= 1; > + create_info.use_default_db_type(thd); > + thd->lex->query_tables->open_strategy= TABLE_LIST::OPEN_STUB; > + thd->lex->create_info.default_table_charset= NULL; > + thd->lex->name= null_lex_str; > + create_table= thd->lex->create_last_non_select_table= thd->lex->last_table(); > + thd->lex->current_select= &thd->lex->select_lex; > + create_table_set_open_action_and_adjust_tables(thd->lex); > + alter_info.create_list= sp->m_cols_list; > + err= mysql_create_table(thd, create_table, &create_info, &alter_info); Ok, so now it is using mysql_create_table instead of parsing the table definition. This is a step forward. However, I still think that mysql_create_table() does too much. It is a function that used for regular CREATE TABLE statements. When I trace a query, I still see that the created temporary table uses InnoDB storage engine. I think, more effort is needed to make temporary table creation work in a more similar to how other parts of code create temporary tables. I think I have also found a problem with how name resolution process works. I'll elaborate in a separate email. > + thd->variables.option_bits|= OPTION_KEEP_LOG; What is this for? please add a comment. > + if (!err) > + close_thread_tables(thd); > + execute_table_function(thd,sp,tables->table_func_params); > + thd->variables.sql_mode= saved_mode; > + lex_end(thd->lex); > + thd->lex= old_lex; > + if (strlen(sp->m_table_alias.str) > 0) { > + tables->table_name= sp->m_table_alias.str; > + tables->mdl_request.init(tables->mdl_request.key.mdl_namespace(), > + tables->db,sp->m_table_alias.str, > + tables->mdl_request.type,tables->mdl_request.duration); > + } What does the above statement do? Please add a comment. > + } > + tables = tables->next_local; > + } > + close_thread_tables(thd); > + return err; > +} ... > +bool execute_table_function(THD *thd, sp_head *sp, List<Item> *value_list) > +{ > + /* bits that should be cleared in thd->server_status */ > + uint bits_to_be_cleared= 0; > + if (sp->m_flags & sp_head::MULTI_RESULTS) > + { > + if (!(thd->client_capabilities & CLIENT_MULTI_RESULTS)) > + { > + /* The client does not support multiple result sets being sent back */ > + my_error(ER_SP_BADSELECT, MYF(0), sp->m_qname.str); > + return 1; > + } > + /* > + If SERVER_MORE_RESULTS_EXISTS is not set, > + then remember that it should be cleared > + */ > + bits_to_be_cleared= (~thd->server_status & > + SERVER_MORE_RESULTS_EXISTS); > + thd->server_status|= SERVER_MORE_RESULTS_EXISTS; > + } Does the above make any sense here? This is a piece of logic from code that executes stored *procedures*. A stored procedure may have multiple SELECT statements. Executing this stored procedure with "CALL sp(...)" may produce multiple result sets. So this logic checks that the client is able to receive multiple resultsets. A stored *function* may not emit resultsets. It must return a scalar value, in our case it must return a table. > + ha_rows select_limit= thd->variables.select_limit; > + thd->variables.select_limit= HA_POS_ERROR; > + > + /* > + 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. > + */ > + int res= sp->execute_procedure(thd, value_list); > + > + thd->variables.select_limit= select_limit; > + thd->server_status&= ~bits_to_be_cleared; > + > + if (res) > + { > + DBUG_ASSERT(thd->is_error() || thd->killed); > + return 1; // Substatement should already have sent error > + } > + > + my_ok(thd, (thd->get_row_count_func() < 0) ? 0 : thd->get_row_count_func()); What is the above for? As far as I understand, the code in this function was based on do_execute_sp(). Which is not a problem, however, do_execute_sp() is used to handle "CALL stored_proc" or compound statements, which should produce "Ok" if they have not produced a resultset. There is no such need when using a table function. Upper query will produce a resultset which it will return to the client. > + thd->reset_query_timer(); What is this for? > + thd->lex->unit.cleanup(); > + thd->mdl_context.release_transactional_locks(); > + thd->reset_for_next_command(); > + return 0; > +} > \ No newline at end of file ... > diff --git a/sql/table.h b/sql/table.h > index 622a3b2..5eddd3d 100644 > --- a/sql/table.h > +++ b/sql/table.h > @@ -2010,6 +2010,7 @@ struct TABLE_LIST > List<Item> used_items; > /* Sublist (tail) of persistent used_items */ > List<Item> persistent_used_items; > + List<Item> *table_func_params; //parameters used for table function. > Item **materialized_items; > > /* View creation context. */ > @@ -2059,7 +2060,7 @@ struct TABLE_LIST > from I_S should be done by create_sort_index() or by JOIN::exec.) > */ > enum enum_schema_table_state schema_table_state; > - > + bool is_table_function; //Check whether the table is actually a table function. Do I get it right that a TABLE_LIST object that denotes a Table Function invocation always has table_func_params != NULL? If yes, please remove 'bool is_table_function' and add a 'bool is_table_function()' function instead which checks for table_func_params!=NULL. > /* Something like a "query plan" for reading INFORMATION_SCHEMA table */ > IS_table_read_plan *is_table_read_plan; > > @@ -2277,6 +2278,18 @@ struct TABLE_LIST > return false; > } > void set_lock_type(THD* thd, enum thr_lock_type lock); > + void fill_table_func_params(List<Item> param_list) > + { > + table_func_params= new List<Item>; > + List_iterator_fast<Item> it(param_list); > + Item *param; > + param= it++; > + while(param) > + { > + table_func_params->push_back(param); > + param= it++; > + } > + } > > private: > bool prep_check_option(THD *thd, uint8 check_opt_type); BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] MDEV-7502 Provisioning of slave - review
by Kristian Nielsen 17 Aug '15

17 Aug '15

Martin Kaluznik <martin.kaluznik(a)gmail.com> writes: > Earlier you mentioned, that you are able to get my code on build > server to try compile and test runs on various platforms, it would be Ok. I have added you as a developer on https://github.com/MariaDB/server. The way it works is that you push your changes to that repository in a branch that starts with "bb-", eg. "bb-10.1-f4rnham". Then Buildbot will pick up your changes and start building (can take some hours or even a day or two in busy periods). Your builds will appear then on this page: https://buildbot.askmonty.org/buildbot/grid?branch=bb-10.1-f4rnham (Please be careful about not accidentally pushing to main branches (or any other branches) in the main repository until we've completed the review process.) Then when the builds are done, you can use the web interface to check for any failures on special platforms or test configuration, and fix them as appropriate. Meanwhile, I will read through all of your patch, and get back to you with comments. > dbug.c,my_dbug.h > When line like SET GLOBAL debug_dbug="+d,flag"; is executed in > test case, it acquires THR_LOCK_dbug, but when it is tested for > (DBUG_EXECUTE_IF) no lock is used - and it causes data races in > replication threads Hm. The way it usually works is that the test cases SET GLOBAL debug_dbug while the slave threads are stopped. That way there should be no races? You might be right that there is a need for a lock, but I would prefer if that was made as a separate change from MDEV-7502, if possible. But it can be tricky to properly control the slave threads for testing, I will keep this point in mind when I check your test cases, and see if I can come up with concrete suggestions where needed. > Edited *.test,*.result > Updated old test cases, most of them because I have added new log > event type, what increased length of format description event and all > positions in test cases have shifted Right, annoying but expected. The Buildbot might catch a few more that are missed by a standard test run. - Kristian.

3 2

[Maria-developers] Unexpected contents of mysql.gtid_slave_pos
by Giuseppe Maxia 13 Aug '15

13 Aug '15

Using MariaDB 10.0.20, when I set a multi-master environment in which one of the masters has log-slave-updated enabled, I get this strange behavior: -- node#1 select @@server_id; +-------------+ | @@server_id | +-------------+ | 101 | +-------------+ use test; create table t1 (i int not null primary key, msg varchar(50), d date, t time, dt datetime, ts timestamp); use mysql; select * from gtid_slave_pos; +-----------+--------+-----------+--------+ | domain_id | sub_id | server_id | seq_no | +-----------+--------+-----------+--------+ | 0 | 1 | 101 | 1 | +-----------+--------+-----------+--------+ Why is this happening? Is there a reason for the server to log its own transactions? The transaction originated from this same server, but it is effectively filtered off when it comes back from the other node (otherwise we would have a conflict). Note: I get the same behavior if I use multi-source setup where one of the nodes has log-slave-updates enabled. Using different domains for each master does not affect the outcome. Thanks Giuseppe

2 4

[Maria-developers] Interested in Contributing Code to Maria DB.
by Alangi Derick 08 Aug '15

08 Aug '15

Hi, I am Alangi Derick and a computer engineering student(specialty: software engineering) from the University of Buea. I am a junior and i code in C. I have found interest in Maria DB. I have used many DBMS but i will like to develop for MariaDB since it is Open source and it is the one that has caught my interest. I have some contributions to make to this organisation in terms of the Maria DB project. I am very proficient in my skills of programming and will first of all start by fixing some bugs in the Maria DB code base before writing a whole module(implementation of my idea) to add to maria db. I will like if the entire community welcomes and support me so as to make Maria DB a better DBMS for everyone. Thanks and hope to participate in the development. Regards Alangi Derick Ndimnain

2 1