June 2014 - developers - lists.mariadb.org

[Maria-developers] [MDEV-4903] Regarding range support for multi-column IN predicates
by Sergey Petrunia 18 Jun '14

18 Jun '14

Hi, So, MySQL 5.7 has got support for range optimization for multi-column IN predicates: http://optimize-this.blogspot.ru/2013/12/range-access-now-in-in-predicate-n… We've also got a user issue about it: https://mariadb.atlassian.net/browse/MDEV-4903. I'm looking at their IN handling. I don't see anything apparently wrong with it. They don't process multi-column NOT IN, but one can say that they just have a limited scope. Relevant code in opt_range.cc for single-column IN: case … [View More]

1 0

[Maria-developers] problem with update and myisam
by Roberto Spadim 18 Jun '14

18 Jun '14

hi guys, could anyone help me with https://mariadb.atlassian.net/browse/MDEV-6355 thanks -- Roberto Spadim

2 5

Re: [Maria-developers] [Commits] 0eb94ca: MDEV-6137 better help for SET/ENUM sysvars
by Sergey Vojtovich 17 Jun '14

17 Jun '14

Hi Sergei, ok to push. A few minor questions inline. On Mon, Jun 16, 2014 at 06:51:53PM +0200, serg(a)mariadb.org wrote: > revision-id: 0eb94ca810500977eb0336ee30b19e9c0b769bca > parent(s): f61f36b386e8d0c6448297bb84c92e8d9b82be6a > committer: Sergei Golubchik > branch nick: maria > timestamp: 2014-06-16 18:43:26 +0200 > message: > > MDEV-6137 better help for SET/ENUM sysvars > > Auto-generate the allowed list of values for enum/set/flagset options > in --… [View More]help output. But don't do that when the help text already has them. > > Also, remove lists of values from help strings of various options, where > they were simply listed without any additional information. > > --- > mysys/my_getopt.c | 81 +++++++++++++++++++++++++++------ > plugin/server_audit/server_audit.c | 2 +- > sql/log.cc | 3 +- > sql/mysqld.cc | 8 ++-- > sql/sql_plugin.cc | 2 +- > sql/sys_vars.cc | 90 ++++++++----------------------------- > storage/maria/ha_maria.cc | 14 ++---- > storage/myisam/ha_myisam.cc | 7 ++- > storage/xtradb/handler/ha_innodb.cc | 35 +++++++-------- > 9 files changed, 116 insertions(+), 126 deletions(-) Hmmm... no test case affected? > > diff --git a/mysys/my_getopt.c b/mysys/my_getopt.c > index 2e97417..3662757 100644 > --- a/mysys/my_getopt.c > +++ b/mysys/my_getopt.c > @@ -1300,6 +1300,48 @@ static uint print_name(const struct my_option *optp) > return s - optp->name; > } > > +/** prints option comment with indentation and wrapping. > + > + The comment column starts at startpos, and has width of width > + Current cursor position is curpos, returns new cursor position > + > +Note: can print one character beyond width! The above line, is it properly indented? > +*/ > +static uint print_comment(const char *comment, > + int curpos, int startpos, int width) Probably make width local to this function, it doesn't seem to be used by the caller anyway? > +{ > + const char *end= strend(comment); > + int endpos= startpos + width; > + > + for (; curpos < startpos; curpos++) > + putchar(' '); > + > + if (*comment == '.' || *comment == ',') > + { > + putchar(*comment); > + comment++; > + curpos++; > + } > + > + while (end - comment > endpos - curpos) > + { > + const char *line_end; > + for (line_end= comment + endpos - curpos; > + line_end > comment && *line_end != ' '; > + line_end--); > + for (; comment < line_end; comment++) > + putchar(*comment); I would probably replace it with fwrite(), but fine with this form too. > + while (*comment == ' ') > + comment++; /* skip the space, as a newline will take it's place now */ > + putchar('\n'); > + for (curpos= 0; curpos < startpos; curpos++) > + putchar(' '); > + } > + printf("%s", comment); > + return curpos + (end - comment); > +} > + > + > /* > function: my_print_options > > @@ -1309,12 +1351,12 @@ static uint print_name(const struct my_option *optp) > void my_print_help(const struct my_option *options) > { > uint col, name_space= 22, comment_space= 57; > - const char *line_end; > const struct my_option *optp; > DBUG_ENTER("my_print_help"); > > for (optp= options; optp->name; optp++) > { > + const char *typelib_help= 0; > if (!optp->comment) > continue; > if (optp->id && optp->id < 256) > @@ -1359,25 +1401,36 @@ void my_print_help(const struct my_option *options) > col= 0; > } > } > - for (; col < name_space; col++) > - putchar(' '); > if (optp->comment && *optp->comment) Cleanup suggestion: optp->comment can't be NULL here. > { > - const char *comment= optp->comment, *end= strend(comment); > + col= print_comment(optp->comment, col, name_space, comment_space); > > - while ((uint) (end - comment) > comment_space) > + switch (optp->var_type & GET_TYPE_MASK) { > + case GET_ENUM: > + typelib_help= ". One of: "; > + break; > + case GET_SET: > + typelib_help= ". Any combination of: "; > + break; > + case GET_FLAGSET: > + typelib_help= ". Takes a comma-separated list of option=value pairs, " > + "where value is on or off, and options are: "; > + break; > + } > + if (typelib_help && > + strstr(optp->comment, optp->typelib->type_names[0]) == NULL) Should we handle case when optp->typelib == NULL || optp->typelib->type_names[0] == NULL? Probably not. I believe this condition is fragile: comment string may mention type_names[0], but not list possible values. OTOH since this condition is for very limited data set it should cause problems only in rare cases. > { > - for (line_end= comment + comment_space; *line_end != ' '; line_end--); > - for (; comment != line_end; comment++) > - putchar(*comment); > - comment++; /* skip the space, as a newline will take it's place now */ > - putchar('\n'); > - for (col= 0; col < name_space; col++) > - putchar(' '); > + int i; > + col= print_comment(typelib_help, col, name_space, comment_space); > + col= print_comment(optp->typelib->type_names[0], col, name_space, comment_space); > + for (i= 1; i < optp->typelib->count; i++) > + { > + col= print_comment(", ", col, name_space, comment_space); > + col= print_comment(optp->typelib->type_names[i], col, name_space, comment_space); > + } > } > - printf("%s", comment); > + putchar('\n'); > } > - putchar('\n'); Does this mean if comment is empty there won't be a new line? > if ((optp->var_type & GET_TYPE_MASK) == GET_BOOL) > { > if (optp->def_value != 0) ...skip... > @@ -2785,7 +2745,7 @@ static Sys_var_mybool Sys_master_verify_checksum( > > /* These names must match RPL_SKIP_XXX #defines in slave.h. */ > static const char *replicate_events_marked_for_skip_names[]= { > - "replicate", "filter_on_slave", "filter_on_master", 0 > + "REPLICATE", "FILTER_ON_SLAVE", "FILTER_ON_MASTER", 0 > }; Does this mean there is a convention that values must be in upper case? ...skip... Regards, Sergey [View Less]

2 1

[Maria-developers] WebScaleSQL: Actually fix all the array bounds warnings
by Sergey Vojtovich 16 Jun '14

16 Jun '14

Hi Sergei and Alexey, during our recent discussion re WebScaleSQL patches we agreed to review $subj: https://github.com/webscalesql/webscalesql-5.6/commit/094187c4a20e8d0c02f17… All these warnings come from strings/decimal.c. I was able to reproduce them using gcc-4.8.1, cmake -DBUILD_CONFIG=mysql_release (basically needs -Wall -O3). I simplified this function to the following: gcc -Wall -O3 -c dec.c -o dec.o static const int powers10[2 + 1]= { 1, 10, 100 }; int remove_leading_zeroes(int … [View More]

2 2

[Maria-developers] MariaDB 10.0.12 release prep
by Daniel Bartholomew 14 Jun '14

14 Jun '14

I've begun prep work for the MariaDB 10.0.12 release. Draft Release Notes and Changelog are here: - https://mariadb.com/kb/en/mariadb-10012-release-notes/ - https://mariadb.com/kb/en/mariadb-10012-changelog/ Please add/modify/etc... as needed. Current plan is to announce the release on Mon, 16 Jun 2014. Thanks! -- Daniel Bartholomew, MariaDB Release Manager MariaDB | http://mariadb.com

1 0

Re: [Maria-developers] Rev 3986: MDEV-5231: Per query variables from Percona Server
by Sergei Golubchik 14 Jun '14

14 Jun '14

Hi, Sanja! On May 22, sanja(a)askmonty.org wrote: > === added file 'mysql-test/suite/percona/percona_rpl_stm_per_query_variables_settings.test' > --- a/mysql-test/suite/percona/percona_rpl_stm_per_query_variables_settings.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/suite/percona/percona_rpl_stm_per_query_variables_settings.test 2014-05-22 12:50:01 +0000 could you rename tests to have shorter names? rpl_set_statement looks good enough to me > @@ -0,0 +1,57 @@ > +--source … [View More]include/master-slave.inc > +--source include/have_binlog_format_statement.inc > + > +--disable_warnings > +DROP TABLE IF EXISTS t1; > +DROP TABLE IF EXISTS t2; > +--enable_warnings > + > +call mtr.add_suppression("Unsafe statement written to the binary log*"); > +CREATE TABLE t1 (a bigint unsigned not null); > +CREATE TABLE t2 (a char(255) not null); okay, although I wouldn't bother creating *two* tables, I'd create one and hard-coded it into percona_rpl_set_statement_variable_test.inc (removing rpl_ssvt_table parameter) > + > +--echo > +--echo There are the following types of variables: > +--echo 1) variables that are NOT replicated correctly when using STATEMENT mode; > +--echo > + > +--let $rpl_ssvt_var_name=max_join_size > +--let $rpl_ssvt_var_value=2 > +--let $rpl_ssvt_table=t1 > +--source suite/percona/percona_rpl_set_statement_variable_test.inc > + > +--echo > +--echo 2) variables thar ARE replicated correctly > +--echo They must be replicated correctly with "SET STATEMENT" too. > +--echo > +--let $rpl_ssvt_var_name=auto_increment_increment > +--let $rpl_ssvt_var_value=10 > +--let $rpl_ssvt_table=t1 > +--source suite/percona/percona_rpl_set_statement_variable_test.inc > + > +--echo > +--echo 3) sql_mode which is replicated correctly exept NO_DIR_IN_CREATE value; > +--echo > +--let $rpl_ssvt_var_name=sql_mode > +--let $rpl_ssvt_var_value='ERROR_FOR_DIVISION_BY_ZERO' > +--let $rpl_ssvt_table=t2 > +--source suite/percona/percona_rpl_set_statement_variable_test.inc > +--let $rpl_ssvt_var_name=sql_mode > +--let $rpl_ssvt_var_value='NO_DIR_IN_CREATE' > +--let $rpl_ssvt_table=t2 > +--source suite/percona/percona_rpl_set_statement_variable_test.inc > + > +--echo > +--echo 4) variables that are not replicated at all: > +--echo default_storage_engine, storage_engine, max_heap_table_size > +--echo > +--let $rpl_ssvt_var_name=max_heap_table_size > +--let $rpl_ssvt_var_value=16384 > +--let $rpl_ssvt_table=t1 > +--source suite/percona/percona_rpl_set_statement_variable_test.inc > + > +connection master; > +DROP TABLE t1; > +DROP TABLE t2; > +sync_slave_with_master; > +source include/stop_slave.inc; > > === added file 'mysql-test/suite/percona/percona_statement_set.result' > --- a/mysql-test/suite/percona/percona_statement_set.result 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/suite/percona/percona_statement_set.result 2014-05-22 12:50:01 +0000 reverse polish notation in percona someone loves. starwars too much seen he apparently. Please, rename to "set_statement.result" > @@ -0,0 +1,875 @@ > +'# SET STATEMENT ..... FOR .... TEST' > +DROP TABLE IF EXISTS t1; > +DROP FUNCTION IF EXISTS myProc; > +DROP PROCEDURE IF EXISTS p1; > +DROP PROCEDURE IF EXISTS p2; > +DROP PROCEDURE IF EXISTS p3; > +DROP PROCEDURE IF EXISTS p4; > +DROP PROCEDURE IF EXISTS p5; > +DROP TABLE IF EXISTS STATEMENT; > +'# Setup database' > +CREATE TABLE t1 (v1 INT, v2 INT); > +INSERT INTO t1 VALUES (1,2); > +INSERT INTO t1 VALUES (3,4); > +'' > +'#------------------ STATEMENT Test 1 -----------------------#' > +'# Initialize variables to known setting' > +SET SESSION sort_buffer_size=100000; > +'' > +'# Pre-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +Variable_name Value > +sort_buffer_size 100000 > +SET STATEMENT sort_buffer_size=150000 FOR SELECT * FROM t1; > +v1 v2 > +1 2 > +3 4 > +'' > +'# Post-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +Variable_name Value > +sort_buffer_size 100000 > +'' > +'#------------------ STATEMENT Test 2 -----------------------#' > +'# Initialize variables to known setting' > +SET SESSION binlog_format=mixed; > +SET SESSION sort_buffer_size=100000; > +'# Pre-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +Variable_name Value > +sort_buffer_size 100000 > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > +Variable_name Value > +binlog_format MIXED > +SET STATEMENT sort_buffer_size=150000, binlog_format=row > +FOR SELECT * FROM t1; > +v1 v2 > +1 2 > +3 4 > +'# Post-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +Variable_name Value > +sort_buffer_size 100000 > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > +Variable_name Value > +binlog_format MIXED > +'' > +'#------------------ STATEMENT Test 3 -----------------------#' > +'# set initial variable value, make prepared statement > +SET SESSION binlog_format=row; > +PREPARE stmt1 FROM 'SET STATEMENT binlog_format=row FOR SELECT * FROM t1'; > +'' > +'# Change variable setting' > +SET SESSION binlog_format=mixed; > +'' > +'# Pre-STATEMENT variable value' > +'' > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > +Variable_name Value > +binlog_format MIXED > +'' > +EXECUTE stmt1; > +v1 v2 > +1 2 > +3 4 > +'' > +'# Post-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > +Variable_name Value > +binlog_format MIXED > +'' > +DEALLOCATE PREPARE stmt1; > +'#------------------ STATEMENT Test 4 -----------------------#' > +'# set initial variable value, make prepared statement > +SET SESSION myisam_sort_buffer_size=500000, myisam_repair_threads=1; > +'' > +'# Pre-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'myisam_sort_buffer_size'; > +Variable_name Value > +myisam_sort_buffer_size 500000 > +SHOW SESSION VARIABLES LIKE 'myisam_repair_threads'; > +Variable_name Value > +myisam_repair_threads 1 > +'' > +SET STATEMENT myisam_sort_buffer_size=800000, > +myisam_repair_threads=2 FOR OPTIMIZE TABLE t1; how comes that is "make prepared statement" (see comment above) ? > +Table Op Msg_type Msg_text > +test.t1 optimize status OK > +'' > +'# Post-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'myisam_sort_buffer_size'; > +Variable_name Value > +myisam_sort_buffer_size 500000 > +SHOW SESSION VARIABLES LIKE 'myisam_repair_threads'; > +Variable_name Value > +myisam_repair_threads 1 > +'' ... > === added file 'mysql-test/suite/percona/percona_statement_set.test' > --- a/mysql-test/suite/percona/percona_statement_set.test 1970-01-01 00:00:00 +0000 > +++ b/mysql-test/suite/percona/percona_statement_set.test 2014-05-22 12:50:01 +0000 > @@ -0,0 +1,847 @@ > +--echo '# SET STATEMENT ..... FOR .... TEST' many of the tests below are pretty useless. they don't test that the value is actually set. See below: > +############################ STATEMENT_SET ############################# > +# # > +# Testing working functionality of SET STATEMENT # > +# # > +# # > +# There is important documentation within # > +# # > +# # > +# Author: Joe Lukas # > +# Creation: # > +# 2009-08-02 Implement this test as part of # > +# WL#681 Per query variable settings # > +# # > +######################################################################## > + > +--disable_warnings > +DROP TABLE IF EXISTS t1; > +DROP FUNCTION IF EXISTS myProc; > +DROP PROCEDURE IF EXISTS p1; > +DROP PROCEDURE IF EXISTS p2; > +DROP PROCEDURE IF EXISTS p3; > +DROP PROCEDURE IF EXISTS p4; > +DROP PROCEDURE IF EXISTS p5; > +DROP TABLE IF EXISTS STATEMENT; > +--enable_warnings > +#################################################################### > +#Set up current database > +#################################################################### > +--echo '# Setup database' > +CREATE TABLE t1 (v1 INT, v2 INT); > +INSERT INTO t1 VALUES (1,2); > +INSERT INTO t1 VALUES (3,4); > +--echo '' > +--echo '#------------------ STATEMENT Test 1 -----------------------#' > +#################################################################### > +# Checks with variable value type ulong # > +#################################################################### > +--echo '# Initialize variables to known setting' > +SET SESSION sort_buffer_size=100000; > +--echo '' > +--echo '# Pre-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +SET STATEMENT sort_buffer_size=150000 FOR SELECT * FROM t1; How do you know that SET STATEMENT did anything at all? > +--echo '' > +--echo '# Post-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +--echo '' > +--echo '#------------------ STATEMENT Test 2 -----------------------#' > +#################################################################### > +# Checks for multiple set values inside STATEMENT ... FOR # > +#################################################################### > +--echo '# Initialize variables to known setting' > +SET SESSION binlog_format=mixed; > +SET SESSION sort_buffer_size=100000; > +--echo '# Pre-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > +SET STATEMENT sort_buffer_size=150000, binlog_format=row > + FOR SELECT * FROM t1; > +--echo '# Post-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'sort_buffer_size'; > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > + > +--echo '' > +--echo '#------------------ STATEMENT Test 3 -----------------------#' > +#################################################################### > +# Check current variable value is stored in using stored # > +# statements. # > +#################################################################### > +--echo '# set initial variable value, make prepared statement > +SET SESSION binlog_format=row; > +PREPARE stmt1 FROM 'SET STATEMENT binlog_format=row FOR SELECT * FROM t1'; How will you know that SET STATEMENT did anything at all? (the same applies to most tests below, I'll stop repeating it) > +--echo '' > +--echo '# Change variable setting' > +SET SESSION binlog_format=mixed; > +--echo '' > +--echo '# Pre-STATEMENT variable value' > +--echo '' > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > +--echo '' > +EXECUTE stmt1; > +--echo '' > +--echo '# Post-STATEMENT variable value' > +SHOW SESSION VARIABLES LIKE 'binlog_format'; > + > +--echo '' > +DEALLOCATE PREPARE stmt1; ... > === modified file 'sql/share/errmsg-utf8.txt' > --- a/sql/share/errmsg-utf8.txt 2014-02-11 13:21:48 +0000 > +++ b/sql/share/errmsg-utf8.txt 2014-05-22 12:50:01 +0000 > @@ -7067,3 +7067,5 @@ ER_IT_IS_A_VIEW 42S02 > eng "'%-.192s' is a view" > ER_SLAVE_SKIP_NOT_IN_GTID > eng "When using GTID, @@sql_slave_skip_counter can not be used. Instead, setting @@gtid_slave_pos explicitly can be used to skip to after a given GTID position." > +ER_SET_STATEMENT_TABLES_IS_NOT_SUPPORTED > + eng "SET STATEMENT does not support using tables in the assignment variables expressions" why not? > > === modified file 'sql/sql_parse.cc' > --- a/sql/sql_parse.cc 2014-03-29 10:33:25 +0000 > +++ b/sql/sql_parse.cc 2014-05-22 12:50:01 +0000 > @@ -2430,6 +2432,33 @@ mysql_execute_command(THD *thd) > thd->get_binlog_format(&orig_binlog_format, > &orig_current_stmt_binlog_format); > > + if (lex->set_statement && !lex->var_list.is_empty()) Hmm? No separate list of variables, but a common lex->var_list? Then the following won't work: SET STATEMENT A=1 SET B=2 I remember in the WL and in GSoC we agreed that for SET STATEMENT A=2 SET A=2 (same variable in SET STATEMENT and SET), it's acceptable to restore the original value of A, basically ignoring SET. But I doubt that the same logic applies when SET STATEMENT and SET modify *different* variables. > + { > + MEM_ROOT *save_mem_root; > + /* > + We should be sure that variables backup and assignment made on > + runtime memory > + */ > + save_mem_root= thd->mem_root; > + thd->mem_root= thd->get_execution_mem_root(); Why? > + per_query_variables_backup= copy_system_variables(&thd->variables); > + if (!per_query_variables_backup || > + (res= sql_set_variables(thd, &lex->var_list))) > + { > + thd->mem_root= save_mem_root; > + /* > + We encountered some sort of error, but no message was sent. > + Send something semi-generic here since we don't know which > + assignment in the list caused the error. > + */ > + if (!thd->is_error()) > + my_error(ER_WRONG_ARGUMENTS, MYF(0), "SET"); > + goto error; > + } > + thd->mem_root= save_mem_root; > + } > + > /* > Force statement logging for DDL commands to allow us to update > privilege, system or statistic tables directly without the updates > @@ -5144,6 +5179,30 @@ finish: > > lex->unit.cleanup(); > > + if (lex->set_statement && !lex->var_list.is_empty()) { > + List_iterator_fast<set_var_base> it(thd->lex->var_list); > + set_var *var; > + > + free_system_variables(&thd->variables); > + thd->variables= *per_query_variables_backup; > + /* per_query_variables_backup was in a mem_root */ > + per_query_variables_backup= NULL; > + /* > + When variables are restored after "SET STATEMENT ... FOR ..." statement > + execution an update callback must be invoked for the system variables > + to save special logic if it is. set_var_base class does not contain > + refference to variable as it is just an interface class. But only > + system variables are allowed to be used in "SET STATEMENT ... FOR ..." > + statement, so cast from set_var_base* to set_var* can be used here. > + */ > + while ((var=(set_var *)it++)) > + { > + var->var->stmt_update(thd); > + } I don't think it'll work. Compare set_var::update() and set_var::stmt_update(). The former calls ::session_update(), while the latter does not. Normally, session_update() simply updates the value, performs the assignment. And it is, indeed, not needed here. but in some custom classes session_update() is more complex, and it's not safe to omit it. Please 1) see all non-trivial implementations of sys_var::session_update() 2) write SET SESSION tests for these variables 3) if they'll all work - please explain why 4) if they won't - I'm afraid, this whole approach needs to be redone, then > + > + thd->lex->set_statement= false; > + } > + > if (! thd->in_sub_stmt) > { > if (thd->killed != NOT_KILLED) > > === modified file 'sql/sql_plugin.cc' > --- a/sql/sql_plugin.cc 2014-03-26 21:25:38 +0000 > +++ b/sql/sql_plugin.cc 2014-05-22 12:50:01 +0000 > @@ -4088,3 +4088,48 @@ static void restore_ptr_backup(uint n, s > (backup++)->restore(); > } > > + > +/** > + Create deep copy of system_variables instance. > +*/ > +struct system_variables * > +copy_system_variables(const struct system_variables *src) What is it doing in sql_plugin.cc? > +{ > + struct system_variables *dst; > + > + DBUG_ASSERT(src); > + > + dst= (struct system_variables *) > + sql_alloc(sizeof(struct system_variables)); > + if (!dst) > + return NULL; > + *dst= *src; > + > + if (dst->dynamic_variables_ptr) > + { > + if (!(dst->dynamic_variables_ptr= > + (char *)my_malloc(dst->dynamic_variables_size, MYF(MY_WME | MY_FAE)))) > + return NULL; > + memcpy(dst->dynamic_variables_ptr, > + src->dynamic_variables_ptr, > + src->dynamic_variables_size); > + } > + > + mysql_mutex_lock(&LOCK_plugin); > + dst->table_plugin= > + intern_plugin_lock(NULL, src->table_plugin); I'm surprised that plugin locking actually works in here, (I believe it does, otherwise you'd noticed it). What about SET STATEMENT default_engine=MEMORY ? What about SET STATEMENT default_engine=MyISAM (where MyISAM is already default)? please, try both in debug build. > + mysql_mutex_unlock(&LOCK_plugin); > + > + return dst; > +} > + > +void free_system_variables(struct system_variables *v) > +{ > + DBUG_ASSERT(v); > + > + mysql_mutex_lock(&LOCK_plugin); > + intern_plugin_unlock(NULL, v->table_plugin); > + mysql_mutex_unlock(&LOCK_plugin); > + > + my_free(v->dynamic_variables_ptr); > +} > > === modified file 'sql/sql_yacc.yy' > --- a/sql/sql_yacc.yy 2014-03-26 21:25:38 +0000 > +++ b/sql/sql_yacc.yy 2014-05-22 12:50:01 +0000 > @@ -813,8 +813,10 @@ static void sp_create_assignment_lex(THD > lex->one_shot_set= 0; > lex->autocommit= 0; > /* get_ptr() is only correct with no lookahead. */ > - DBUG_ASSERT(no_lookahead); > + if (no_lookahead) > lex->sphead->m_tmp_query= lip->get_ptr(); > + else > + lex->sphead->m_tmp_query= lip->get_tok_end(); Why? > /* Inherit from outer lex. */ > lex->option_type= old_lex->option_type; > } > @@ -955,10 +957,10 @@ bool my_yyoverflow(short **a, YYSTYPE ** > %parse-param { THD *thd } > %lex-param { THD *thd } > /* > - Currently there are 163 shift/reduce conflicts. > + Currently there are 164 shift/reduce conflicts. > We should not introduce new conflicts any more. > */ > -%expect 163 > +%expect 164 Why? > > /* > Comments for TOKENS. > @@ -14427,8 +14431,44 @@ set: > } > start_option_value_list > {} > + | SET STATEMENT_SYM > + { > + LEX *lex= Lex; > + mysql_init_select(lex); > + lex->sql_command= SQLCOM_SET_OPTION; > + /* Don't clear var_list in the case of recursive statement */ > + if (!lex->set_statement) > + lex->var_list.empty(); When var_list is not empty here (and set_statement not set)? In other words, when this statement will actually have any effect? > + lex->one_shot_set= 0; > + lex->autocommit= 0; > + lex->set_statement= true; > + sp_head *sp= lex->sphead; > + if (sp && !sp->is_invoked()) > + { > + sp->m_param_begin= ((yychar == YYEMPTY) ? YYLIP->get_ptr() : YYLIP->get_tok_start()); > + sp->m_param_end= ((yychar == YYEMPTY) ? YYLIP->get_ptr() : YYLIP->get_tok_end()); Why? > + } > + } > + set_stmt_option_value_following_option_type_list Eh? What does "set stmt option value following option type list" mean? Please, rename to set_stmt_option_value_list or even set_stmt_list > + { > + if (Lex->query_tables) > + { > + my_error(ER_SET_STATEMENT_TABLES_IS_NOT_SUPPORTED, MYF(0)); > + MYSQL_YYABORT; > + } > + } > + FOR_SYM statement > + {} > ; > > +set_stmt_option_value_following_option_type_list: > + /* > + Only system variables can be used here. If this condition is changed > + please check careful code under lex->option_type == OPT_STATEMENT > + condition on wrong type casts. > + */ > + option_value_following_option_type > + | set_stmt_option_value_following_option_type_list ',' option_value_following_option_type > > // Start of option value list > start_option_value_list: Regards, Sergei [View Less]

1 0

Re: [Maria-developers] [GSoC] self-tuning optimizer
by Sergei Golubchik 14 Jun '14

14 Jun '14

Hi, Anshu! On Jun 13, Anshu Avinash wrote: > > So I have refactored Cost_factors::init() into Cost_factors::init() and > Cost_factors::re_init(). The diff is at: > https://github.com/igniting/server/commit/41e360309c067d072d788495e4e948054… Looks great. I've added one comment there. > I had started writing a test for checking whether if loading a new > storage engine works or not. I loaded 'Example' storage engine, but > was unable to test the current t1 table on it, as … [View More]t1 contains a > primary key. Also I need to write test cases for 'time_for_compare'. > Any hints on that? Hm. Yes. Example engine, is pretty useless for you, as you cannot create tables in it. You can use InnoDB plugin. But create a separate test file for that. For example (I'll use the short name below, don't commit it): a.test: ============================================== if (!$HA_INNODB_SO) { skip Need InnoDB plugin; } install plugin innodb soname 'ha_innodb'; ... do your tests here uninstall plugin innodb; ============================================== you will also need a.opt file: ============================================== --ignore-builtin-innodb --loose-innodb ============================================== As for time_for_compare... Here's a universal approach, you can do it yourself. This time_for_compare is 5 by default, right? Change it to be, say, 500, and run existing tests (start from the main suite, and there from optimizer tests, e.g. from select.test). If some test will fail - here's your query, extract it, simplify, perhaps, and put in your test file. That's exactly what I just did :) And here's a simple test: create table t1 (a blob, index(a(20))); create table t2 (a blob, index(a(20))); insert into t1 values ('one'),('two'),('three'),('four'),('five'); insert into t2 values ('one'),('two'),('three'),('four'),('five'); insert into t2 values ('one'),('two'),('three'),('four'),('five'); drop table t1, t2; Perhaps you can get it down to one table - I didn't try. > Also I think I can start with the next part, i.e. collect statistics. We > can have a structure like: > > struct Cost_factor_stats > { > char *cost_factor_name; > double cost_factor_value; > double total_queries; total_queries should be ulonglong, not double. > double total_query_time; > double total_query_time_squared; > }; > > We will be updating these structures after every query per THD and write > the data into a persistent table on disconnect. Is this workflow correct? Almost. You need a Cost_factor_stats structure per cost factor (and per engine where appropriate). You don't need the name there. You have these structures per THD and globally. Basically, instead of your current double time_for_compare_val; you will have Cost_factor_stats time_for_compare_val; hmm, perhaps better to name the structure simply "Cost_factor": Cost_factor time_for_compare; And you put them all in one structure: struct Engine_cost_factors { Cost_factor read_time; Cost_factor scan_time; }; struct Global_cost_factors { Cost_factor time_for_compare; Cost_factor time_for_compare_rowid; }; class Cost_factors { Global_cost_factors global; Engine_cost_factors engine[MAX_HA]; double time_for_compare() const { return global.read_time.value; } double time_for_compare_rowid() const; double read_time(const handler*) const; double scan_time(const handler*) const; }; Now, you stick this structure in the THD, and also declare one instance globally. On connect you initialize THD::Cost_factor values from the global Cost_factor object. On disconnect you add THD::Cost_factor values back to the global Cost_factor object. There's no writing to disk so far, we'll think about it later (you don't want to write to disk on *every* disconnect). > Few more questions: > 1.What will we do if the query had used more than one cost factor? > 2.How would joins be handled? Yes, a query will certainly use more than one cost factor. In fact, this is something we might want to experiment with. I see two approaches - exact and approximate. Approximate one is described in MDEV. Say, you've counted 500 index reads, 20,000 sequential row reads (table scan), some 10,000,000 comparisons, etc. And you know how long the query took. For another query you've counted different numbers, and so on. Basically, you'll have a system of linear equations that one can solve to know how the time was split. The problem with this approach - the server is doing much more than purely index reads, table scans, and comparisons. So this unaccounted time will be split between cost factors. I don't know if it's a problem. The exact approach - we only measure times spent on the actual operation. Basically, you measure how long *each row read* took, how long *each index read* took, etc. This will show no unaccounted time. But it's more expensive, it might be too expensive to be practically useful - I don't know that. These two approaches need different data structures, the first one needs more memory, because you cannot start aggregating before you solve the system of equations. Basically, if you have four constant (time_for_compare, time_for_compare_rowid, read_time, scan_time, only one engine), you'll need four equations, that is, per THD you need to store four measurements: struct measurement { ulong time_for_compare; ulong time_for_compare_rowid; struct per_engine { ulong scan_time; ulong read_time; } per_engine[MAX_HA]; double total_time; }; and in THD you need struct measurement data[4]; Also, note that I'm writing per_engine[MAX_HA], but it's a simplification, good enough for a prototype. But in the final code we cannot allocate that much memory per THD, as most of the time we'll have only few engines, not MAX_HA. Regards, Sergei [View Less]

1 0

[Maria-developers] WebScaleSQL: Adjust linking flags to not embed some libs
by Sergey Vojtovich 13 Jun '14

13 Jun '14

Hi Sergei, during our recent discussion re WebScaleSQL patches we agreed to accept $subj: https://github.com/webscalesql/webscalesql-5.6/commit/361e3b83145402945b737… I studied our binaries and it looks like we embed zlib and ssl libraries only if WITH_ZLIB=bundled/WITH_SSL=bundled. E.g. DEB/RPM packages use system libs and do not embed zlib/ssl, whereas tarball uses bundled zlib/yassl and embeds them. Not embedding yassl into the client library will make the latter almost useless. Same … [View More]

2 1

[Maria-developers] Java Connector Coding till 12th June
by Puneet Dewan 13 Jun '14

13 Jun '14

Hi Everyone, This week, I was able to send the com_stmt_execute command from the *Driver * in the way it is accepted by the MariaDB server So, Now I am able to insert a row in the database using com_stmt_execute command. But from the console when I try to see the values I see *NULL* I used *Wireshark* to capture the packets,but I can see the value(Varchar /Int/..etc) is passed in the packet which wireshark captures. I am investigating the code but could not find anything till now. In Wireshark … [View More]it shows* [Expert Info (warn/undecoded) :FIXME: Excute Dissector Incomplete]* Now I think I am not sending the values in a correct format.Will look and try to resolve it. Regards Puneet. On Thu, Jun 5, 2014 at 10:42 PM, Puneet Dewan <puneetd30(a)gmail.com> wrote: > Hi Everyone, > > The work done till 5th June: > 1.I started studying the connector immediately after my semester exams got > over(5th May). > 2. Understood the relationship between different classes. > 3.Read the MySql documentation for text protocol and map the commands from > documentation onto code.This thing gave a clear idea about how things are > moving from client to server. > 4.Setup the code on Ubuntu using eclipse and tested against database. > Setup the Team branch in launchpad. > 5.Debug the test classes to see how different classes are interlinked and > understood that MySQLProtocol.java is the heart of our JDBC driver. > 6.Then I started reading Client Server Protocol documentation i.e > ServerSide prepared statement and try to see how and where I have to code > it. > 7.Then I saw that there is a class MySqlServerSidePreparedStatement.java, > Initially I coded the prepareStatement() ,close(),and execute() in that > class seperately. > But after (Code review) discussion with Massimo, we donot need to use that > class. > Instead use MySqlPreparedStatement.java to do the same work.So made > changes accordingly. > 8.I had pushed some of the code which I have written to launchpad and > discussed with Massimo last week. > 9.Last week I was struck with Wireshark on windows and ubuntu both. > I was unable to see the packets going to database and seeing the response. > 10.On Monday the problem was resolved as I was using the wrong interface.I > should have used loopback.io(127.0.0.1) instead on ubuntu(thanks to > Georg). > Unfortunately the thing does not work on windows.Tried a lot many times. > 11.Now I am working on the execute method of client server protocol as I > am getting exception while using that method.Wireshark is playing a great > role in how the packets are flowing. > > From now I will do weekly blogging and keep everyone updated. > > Thanks & Regards > Puneet. > [View Less]

1 0

[Maria-developers] Allow to turn off max_connect_errors
by Honza Horak 13 Jun '14

13 Jun '14

Hi guys, there are apparently some tools out there [1], that check if the server is up quite often, while not closing the connection properly. It eventually ends in 'many connection errors', because max_connect_errors is always limited now. I understand that this way of checking may be wrong, but there may be scenarios where we do not want to check for `max_connect_errors` at all. So, would it be acceptable for mariadb to change behaviour of max_connect_errors option, so that it accepts … [View More]

4 4