- developers - lists.mariadb.org

[Maria-developers] GSoC 2013
by Dammina Sahabandu 17 Apr '13

17 Apr '13

Hi All, I'm Dammina Sahabandu, 3rd year undergraduate of University of Moratuwa(dept. of Computer of Science and Engineering) which has consecutively won GSOC’s most number of participant’s award from 2009 to 2012. I'm willing to contribute for a MariaDB project in this years GSoC. I went through the project ideas page and found the project "Self-Tuning Optimizer" interesting. So can you give me an insight of the project. -regards Dammina

2 1

[Maria-developers] MDEV-260 auditing table accesses
by Sergei Golubchik 17 Apr '13

17 Apr '13

Hi, Monty, Here's a patch for MDEV-260 (auditing table accesses). Please review and see whether it's safe for 5.5. Regards, Sergei

1 0

[Maria-developers] Bug in MariaDB 5.5.30 mysql_secure_installation: find_mysql_client command not found
by Viljo Hakala 16 Apr '13

16 Apr '13

When I rn mysql_secure_installation I get a warning: "379: find_mysql_client: command not found" On line 379 on mysql_secure_installation find:mysql_client command/function is called, but there is no such command and no such definition of command in MariaDB 5.5.30. It doesn't cause a problem -- the script runs successfully, but it is just a small annoying message. Can this be fixed?

2 2

Re: [Maria-developers] incomplete index stats in MariaDB
by Axel Schwenke 16 Apr '13

16 Apr '13

Igor Babaev wrote: > On 04/12/2013 09:00 AM, Axel Schwenke wrote: >> Hi Igor, Timour, >> >> when I wrote the script to translate MariaDB table statistics to MySQL, >> I found one problem. Imagine this simple table: >> >> create table t1 (c1 int, c2 int, c3 int, >> primary key (c1, c2), >> index `secondary`(c3)); >> >> Here the secondary index has 3 parts, it can be used as (c3), (c3, c1) >> and (c3, c1, c2). Obviously the avg_frequency is 1 for (c3, c1, c2), but >> it is not obvious how it is for (c3, c1). Such data I'd expect to see in >> the index_stats table under prefix_arity=2, but it's not there. > > To get this you have to run analyze with > set optimizer_switch='extended_keys=on'; Thanks Igor, this is a piece I was missing. While I see the point to obey the extended_keys optimizer switch in ANALYZE TABLE, I wonder if this is a good idea. The optimizer switch is dynamic, so a user can change it, even for a single query. But when the statistics for the extended key is not available, this makes not much sense. I suggest to always collect extended keys statistics, regardless of the setting of the extended_keys optimizer switch. Rationale: it is easy to simply not use the data when extended_keys=off. The only counter argument would be that this is costly - but I cannot see this. XL

1 0

Re: [Maria-developers] I would like to run a buildbot
by Kristian Nielsen 16 Apr '13

16 Apr '13

Dan Demeter <dan(a)apexis.ro> writes: > I would be happy to compile and install the latest CLANG if you > want. Currently I am compiling with > gcc version 4.4.3 ( the stock one from Ubuntu repos ). I think the currently configured builder (dan_demeter1) is fine for now. For the other one, it sounds like a good idea to install CLANG. > Actually, I managed to install Build Slave on a VM and it connected > and it's running. Yes, it seems to be working fine, great! I am looking into the test failures, and I may need help with tracking down one of them. We have a test that causes the server to crash like this: 130414 13:57:41 [ERROR] mysqld got signal 6 ; stack_bottom = 0x0 thread_stack 0x48000 mysys/stacktrace.c:247(my_print_stacktrace)[0xb2ef89] sql/signal_handler.cc:153(handle_fatal_signal)[0x71cb1b] ??:0(??)[0x7f82edc528f0] ??:0(??)[0x7f82ec98fa83] sql/mysqld.cc:5556(handle_connections_sockets())[0x51ca2e] sql/mysqld.cc:5007(mysqld_main(int, char**))[0x52359f] ??:0(??)[0x7f82ec8d1c4d] ??:0(_start)[0x516c4d] Writing a core file As you see, there is not much information to go by. Here are some suggestions you can try on the dan_demeter1 host to get more information available: - Install gdb (if not there already). mysql-test-run can use gdb to obtain better stack traces from core files. - Enable core files in current directory (if not enabled already). It looks like mysql-test-run does not find any core file, even though the log says that one is written. Maybe there is some default ubuntu security configuration or something that disables core files, or puts them in a different location? Not 100% sure, but something to check... - Maybe you can install debug symbols for libc (apt-get install libc6-dbg) to attempt to get better information in the stack trace (if not there already). - Maybe Serg (Cc:'ed) has an idea about what to install to get better stack traces than the above. Thanks, - Kristian.

3 10

[Maria-developers] GSoC 2013: Regex enhancements
by Gábor Kövesdán 14 Apr '13

14 Apr '13

Hi, I'm a student interested in this GSoC project. I already participated in GSoC several times, one of those involved porting the TRE regex engine to FreeBSD. I also worked on some optimizations for that. Since then I've started the PhD course in modeling and domain-specific languages, which made me more familiar with the theory of parsing and automata. I'm experienced in C and I can get along with C++. I'd like to ask what are the exact requirements of this project? Is it about plugging in an existing regexp engine into MariaDB, like RE2 or TRE? Or writing a new implementation? Could you please give me some pointers where to look at the code to see how regexes are used in MariaDB? Also, what other preliminary research should I do to write a good application? Thanks in advance, Gábor

2 1

[Maria-developers] GSOC2013
by Ajaya Agrawal 11 Apr '13

11 Apr '13

Hi All, I am Ajaya and I am interested in participating in gsoc2013. I am interested in gsoc project LDAP authentication plugin and memcached InnoDB interface. Although I have not worked with mariadb before I have submitted couple of working bug-fixes for drizzle. I would like to know which of these two is more important to mariadb? I would like to implement this https://mariadb.atlassian.net/browse/MDEV-4166?jql=project%20in%20(CONC%2C%… I believe I have sufficient theoretical knowledge about the problem but would appreciate if someone can point me to right direction in the codebase. I have compiled and built mariadb on my ubuntu machine. Thank You, Ajaya

2 1

[Maria-developers] We're accepted into Google Summer of Code 2013
by Colin Charles 10 Apr '13

10 Apr '13

Subject says it all We need people to sign up as mentors (http://www.google-melange.com/gsoc/homepage/google/gsoc2013) against the MariaDB project Students start opening up soon If you know of projects a student can complete in 3 months over a summer, this is the ideal place to list the task: https://kb.askmonty.org/en/google-summer-of-code-2013/ This is the first time MariaDB is going to participate. Some of you have done this in the past against MySQL or Drizzle. Big win for MariaDB this year! cheers, -colin -- Colin Charles, http://bytebot.net/blog/ | twitter: @bytebot | skype: colincharles MariaDB: Community developed. Feature enhanced. Backward compatible. Download it at: http://www.mariadb.org/ Open MariaDB/MySQL documentation at the Knowledgebase: http://kb.askmonty.org/

3 2

Re: [Maria-developers] [Commits] Rev 3197: MDEV-4326 fix.
by Sergei Golubchik 09 Apr '13

09 Apr '13

Hi, Oleksandr! On Apr 09, Oleksandr Byelkin wrote: > 09.04.2013 13:38, Sergei Golubchik пишет: > >> === modified file 'sql/sql_prepare.cc' > >> --- a/sql/sql_prepare.cc 2012-11-06 09:52:55 +0000 > >> +++ b/sql/sql_prepare.cc 2013-04-09 06:58:51 +0000 > >> @@ -787,7 +787,7 @@ static bool insert_params_with_log(Prepa > >> if (param->state == Item_param::NO_VALUE) > >> DBUG_RETURN(1); > >> > >> - if (param->limit_clause_param && param->item_type != Item::INT_ITEM) > >> + if (param->limit_clause_param) > > This looks wrong. Why do you need to convert INT_ITEM to INT_ITEM ? > Because it is not INT Item, it is Item with INT cache (which could be > left from previous run). When we assign value from variable we have > exactly the same code (see item.cc). I know that in your bug it's not an INT_ITEM. May be this exactly is a problem? When the param->item_type is not updated correctly for string parameters? > >> === modified file 'tests/mysql_client_test.c' > >> --- a/tests/mysql_client_test.c 2013-04-06 19:29:12 +0000 > >> +++ b/tests/mysql_client_test.c 2013-04-09 06:58:51 +0000 > >> @@ -16750,7 +16750,11 @@ static void test_bug43560(void) > >> fprintf(stdout, "Skipping test_bug43560: server not DEBUG version\n"); > >> DBUG_VOID_RETURN; > >> } > >> - > >> + if (opt_unix_socket) > >> + { > >> + fprintf(stdout, "Skipping test_bug43560: connected via UNIX socket\n"); > >> + DBUG_VOID_RETURN; > >> + } > > Why is that? There's nothing in the bug depends on how the client is > > connected. > they require TCP connection (see following comment). I am not sure that > it is ok to change connection type in the test, so I make it skipped on > unix socket (otherwise it just fails on connection). Ah, it's not your bug. Okay. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] Rev 3197: MDEV-4326 fix.
by Sergei Golubchik 09 Apr '13

09 Apr '13

Hi, Sanja! On Apr 09, sanja(a)askmonty.org wrote: > revno: 3197 > revision-id: sanja(a)askmonty.org-20130409065851-bb241d1scc8lxo3p > parent: sergii(a)pisem.net-20130406192912-jtwuhe78zijfqfbx > committer: sanja(a)askmonty.org > branch nick: work-maria-5.1-MDEV-4326 > timestamp: Tue 2013-04-09 09:58:51 +0300 > message: > MDEV-4326 fix. > > Removed "optimization" which caused preoblems on second execution of > PS with string parameter in LIMIT clause. > > === modified file 'sql/sql_prepare.cc' > --- a/sql/sql_prepare.cc 2012-11-06 09:52:55 +0000 > +++ b/sql/sql_prepare.cc 2013-04-09 06:58:51 +0000 > @@ -787,7 +787,7 @@ static bool insert_params_with_log(Prepa > if (param->state == Item_param::NO_VALUE) > DBUG_RETURN(1); > > - if (param->limit_clause_param && param->item_type != Item::INT_ITEM) > + if (param->limit_clause_param) This looks wrong. Why do you need to convert INT_ITEM to INT_ITEM ? > { > param->set_int(param->val_int(), MY_INT64_NUM_DECIMAL_DIGITS); > param->item_type= Item::INT_ITEM; > > === modified file 'tests/mysql_client_test.c' > --- a/tests/mysql_client_test.c 2013-04-06 19:29:12 +0000 > +++ b/tests/mysql_client_test.c 2013-04-09 06:58:51 +0000 > @@ -16750,7 +16750,11 @@ static void test_bug43560(void) > fprintf(stdout, "Skipping test_bug43560: server not DEBUG version\n"); > DBUG_VOID_RETURN; > } > - > + if (opt_unix_socket) > + { > + fprintf(stdout, "Skipping test_bug43560: connected via UNIX socket\n"); > + DBUG_VOID_RETURN; > + } Why is that? There's nothing in the bug depends on how the client is connected. > /* > Set up a separate connection for this test to avoid messing up the > general MYSQL object used in other subtests. Use TCP protocol to avoid > @@ -17541,6 +17545,109 @@ static void test_bug13001491() > myquery(rc); > } > > +static void test_mdev4326() > +{ > + MYSQL_STMT *stmt; > + MYSQL_BIND bind; > + char query[]= "SELECT * FROM mysql.user LIMIT ?"; > + char str_data[]= "1"; > + unsigned long length= 0; > + int int_data= 1; > + int rc, count; > + my_bool is_null= 0; > + my_bool error= 0; > + myheader("test_mdev4326"); > + > + rc= mysql_change_user(mysql, opt_user, opt_password, "mysql"); > + myquery(rc); Sanja, I asked to reduce the test case and to remove whatever is not relevant to the bug. Why do you need to change user here? It's not needed for the bug to show up. > + > + rc= mysql_query(mysql, "SET GLOBAL general_log = 1"); > + myquery(rc); > + > + stmt= mysql_stmt_init(mysql); > + check_stmt(stmt); > + > + /* Numeric parameter test */ > + > + rc= mysql_stmt_prepare(stmt, query, strlen(query)); > + check_execute(stmt, rc); > + check_stmt(stmt); > + verify_param_count(stmt, 1); > + > + memset((char *)&bind, 0, sizeof(bind)); > + bind.buffer_type= MYSQL_TYPE_LONG; > + bind.buffer= (char *)&int_data; > + bind.is_null= &is_null; > + bind.length= &length; > + bind.error= &error; Why do you execute the statement with MYSQL_TYPE_LONG parameters? It's not needed for the bug to show up. > + > + rc= mysql_stmt_bind_param(stmt, &bind); > + check_execute(stmt, rc); > + rc= mysql_stmt_execute(stmt); > + check_execute(stmt, rc); > + count= 0; > + while (!(rc= mysql_stmt_fetch(stmt))) > + count++; > + DIE_UNLESS(count == 1); > + rc= mysql_stmt_execute(stmt); > + check_execute(stmt, rc); > + count= 0; > + while (!(rc= mysql_stmt_fetch(stmt))) > + count++; > + DIE_UNLESS(count == 1); > + int_data= 0; > + rc= mysql_stmt_execute(stmt); > + check_execute(stmt, rc); > + count= 0; > + while (!(rc= mysql_stmt_fetch(stmt))) > + count++; > + DIE_UNLESS(count == 0); > + rc= mysql_stmt_close(stmt); > + check_execute(stmt, rc); > + > + /* String parameter test */ > + > + stmt= mysql_stmt_init(mysql); > + rc= mysql_stmt_prepare(stmt, query, strlen(query)); > + check_execute(stmt, rc); > + check_stmt(stmt); > + verify_param_count(stmt, 1); > + > + memset((char *)&bind, 0, sizeof(bind)); > + bind.buffer_type= MYSQL_TYPE_STRING; > + bind.buffer= (char *)str_data; > + length= bind.buffer_length= sizeof(str_data); > + bind.is_null= &is_null; > + bind.length= &length; > + bind.error= &error; > + > + rc= mysql_stmt_bind_param(stmt, &bind); > + check_execute(stmt, rc); > + rc= mysql_stmt_execute(stmt); > + check_execute(stmt, rc); > + count= 0; > + while (!(rc= mysql_stmt_fetch(stmt))) > + count++; > + DIE_UNLESS(count == 1); > + rc= mysql_stmt_execute(stmt); > + check_execute(stmt, rc); > + count= 0; > + while (!(rc= mysql_stmt_fetch(stmt))) > + count++; > + DIE_UNLESS(count == 1); > + str_data[0]= '0'; > + rc= mysql_stmt_execute(stmt); > + check_execute(stmt, rc); > + count= 0; > + while (!(rc= mysql_stmt_fetch(stmt))) > + count++; > + DIE_UNLESS(count == 0); > + rc= mysql_stmt_close(stmt); > + check_execute(stmt, rc); > + > + rc= mysql_change_user(mysql, opt_user, opt_password, current_db); > + myquery(rc); Another useless mysql_change_user. > +} > > static struct my_tests_st my_tests[]= { > { "disable_query_logs", disable_query_logs }, > @@ -17790,6 +17897,7 @@ static struct my_tests_st my_tests[]= { > { "test_bug58036", test_bug58036 }, > { "test_bug56976", test_bug56976 }, > { "test_bug13001491", test_bug13001491 }, > + { "test_mdev4326", test_mdev4326 }, > { 0, 0 } > }; Regards, Sergei

1 0