March 2018 - developers - lists.mariadb.org

Re: [Maria-developers] [Commits] b960f68b102: MDEV-11274: Executing EXPLAIN of complex query over join limit causes server to crash
by Sergey Petrunia 21 Mar '18

21 Mar '18

Hi Varun, On Tue, Jan 23, 2018 at 10:49:37AM +0530, Varun wrote: > revision-id: b960f68b102ec72cf75252b357760e99c5dffc18 (mariadb-5.5.56-144-gb960f68b102) > parent(s): a7a4519a40c58947796c6d9b2e4e58acc18aeef8 > author: Varun Gupta > committer: Varun Gupta > timestamp: 2018-01-23 10:31:02 +0530 > message: > > MDEV-11274: Executing EXPLAIN of complex query over join limit causes server to crash > > For this case we have a view that is mergeable but we are not able to merge it in the > parent select because that would exceed the maximum tables allowed in the join list, so we > materialise this view > TABLE_LIST::dervied is NULL for such views, it is only set for views which have ALGORITHM=TEMPTABLE > Fixed by using SELECT_LEX_UNIT representing the result of the query within the view definition ... > diff --git a/sql/table.cc b/sql/table.cc > index 9cade76cb78..8f377d5bda8 100644 > --- a/sql/table.cc > +++ b/sql/table.cc > @@ -6817,9 +6817,8 @@ int TABLE_LIST::fetch_number_of_rows() > if (jtbm_subselect) > return 0; > if (is_materialized_derived() && !fill_me) > - > { > - table->file->stats.records= ((select_union*)derived->result)->records; > + table->file->stats.records= ((select_union*)get_unit()->result)->records; > set_if_bigger(table->file->stats.records, 2); So, regular VIEWs with algorithm=TEMPTABLE have derived == view->unit This is set in mysql_make_view(): ... table->derived_type= VIEW_ALGORITHM_TMPTABLE; DBUG_PRINT("info", ("algorithm: TEMPORARY TABLE")); view_select->linkage= DERIVED_TABLE_TYPE; ... However, the view in the example has algorithm=MERGE so the execution doesn't reach that point. The decision to materialized is made in mysql_derived_merge. It calls derived->set_materialized_derived(); which calls set_check_materialized(); I have discussed this with Sanja, and the outcome is that a better solution would be to set TABLE_LIST::derived when we decide that this view is going to be handled with temp.table strategy. set_check_materialized() seems to be the right place to do it (although its name looks confusing. What does one "check"? Probably the name is a leftover from some feature backport from MySQL). Could you change the patch to set TABLE_LIST::derived and see if that works? BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] [Commits] 0f35480f3d6: MDEV-6707: Wrong result (extra row) with group by, multi-part key
by Sergey Petrunia 20 Mar '18

20 Mar '18

Hi Varun, Nice to see feedback for the first review fixed, but there's more to do. Please find more input below. On Fri, Jan 19, 2018 at 01:07:20AM +0530, Varun wrote: > revision-id: 0f35480f3d60fac91bf1f91f8140ac5f55724139 (mariadb-5.5.56-142-g0f35480f3d6) > parent(s): fafdac3365f4943e73bcefd0e0d07d69997a9724 > author: Varun Gupta > committer: Varun Gupta > timestamp: 2018-01-18 23:53:35 +0530 > message: > > MDEV-6707: Wrong result (extra row) with group by, multi-part key > > This case involves using a composite key,few parts of which are involved in GROUP BY and few in the MIN/MAX > functions in the select list. > Ranges are created in accordance with the where condition, so during the execution of such queries, > we try to find a prefix using the fields involved in GROUP BY > and we then check if this newly returned prefix lies within the range we had calculated earlier. > > For queries which use composite key, few parts of which are involved in GROUP BY and few in the MIN/MAX functtions > in the select list, we try to find the prefix of the ranges by using the fields involved in the group by clause. > We get extra rows in the output when we have same partial ranges created for the fields in the GROUP BY clause > > This issue can be fixed if we compare such partial ranges and don't lookup if we see the same prefix again. > > --- > mysql-test/r/range.result | 14 +++++++++++++ > mysql-test/r/range_mrr_icp.result | 14 +++++++++++++ > mysql-test/t/range.test | 13 ++++++++++++ > sql/opt_range.cc | 44 ++++++++++++++++++++++++++++++++++++--- > sql/opt_range.h | 5 +++-- > 5 files changed, 85 insertions(+), 5 deletions(-) > > diff --git a/mysql-test/r/range.result b/mysql-test/r/range.result > index 630a692cef6..72b31de4df4 100644 > --- a/mysql-test/r/range.result > +++ b/mysql-test/r/range.result > @@ -2144,3 +2144,17 @@ value1 1000685 12345 > value1 1003560 12345 > value1 1004807 12345 > drop table t1; > +# > +# MDEV-6707: Wrong result (extra row) with group by, multi-part key > +# > +CREATE TABLE t1 (f1 INT, f2 VARCHAR(1), KEY(f2,f1)) ENGINE=InnoDB; > +INSERT INTO t1 VALUES > +(7,'v'),(0,'s'),(9,'l'),(4,'c'); > +explain > +SELECT MAX(f1), f2 FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2; > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE t1 range f2 f2 9 NULL 2 Using where; Using index for group-by > +SELECT MAX(f1), f2 FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2; > +MAX(f1) f2 > +4 c > +DROP TABLE t1; > diff --git a/mysql-test/r/range_mrr_icp.result b/mysql-test/r/range_mrr_icp.result > index 3f5de5b0189..1050bfcd887 100644 > --- a/mysql-test/r/range_mrr_icp.result > +++ b/mysql-test/r/range_mrr_icp.result > @@ -2146,4 +2146,18 @@ value1 1000685 12345 > value1 1003560 12345 > value1 1004807 12345 > drop table t1; > +# > +# MDEV-6707: Wrong result (extra row) with group by, multi-part key > +# > +CREATE TABLE t1 (f1 INT, f2 VARCHAR(1), KEY(f2,f1)) ENGINE=InnoDB; > +INSERT INTO t1 VALUES > +(7,'v'),(0,'s'),(9,'l'),(4,'c'); > +explain > +SELECT MAX(f1), f2 FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2; > +id select_type table type possible_keys key key_len ref rows Extra > +1 SIMPLE t1 range f2 f2 9 NULL 2 Using where; Using index for group-by > +SELECT MAX(f1), f2 FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2; > +MAX(f1) f2 > +4 c > +DROP TABLE t1; > set optimizer_switch=@mrr_icp_extra_tmp; > diff --git a/mysql-test/t/range.test b/mysql-test/t/range.test > index 393ca68e945..62e907b7b4a 100644 > --- a/mysql-test/t/range.test > +++ b/mysql-test/t/range.test > @@ -1718,3 +1718,16 @@ where (key1varchar='value1' AND (key2int <=1 OR key2int > 1)); > --echo # The following must show col1=12345 for all rows: > select * from t1; > drop table t1; > + > +--echo # > +--echo # MDEV-6707: Wrong result (extra row) with group by, multi-part key > +--echo # > + > +CREATE TABLE t1 (f1 INT, f2 VARCHAR(1), KEY(f2,f1)) ENGINE=InnoDB; > +INSERT INTO t1 VALUES > +(7,'v'),(0,'s'),(9,'l'),(4,'c'); > + > +explain > +SELECT MAX(f1), f2 FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2; > +SELECT MAX(f1), f2 FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2; > +DROP TABLE t1; > diff --git a/sql/opt_range.cc b/sql/opt_range.cc > index 25a9e729a8b..be959764b16 100644 > --- a/sql/opt_range.cc > +++ b/sql/opt_range.cc > @@ -11249,6 +11249,7 @@ int QUICK_RANGE_SELECT::get_next() > @param prefix_length length of cur_prefix > @param group_key_parts The number of key parts in the group prefix > @param cur_prefix prefix of a key to be searched for > + @param save_last_range INOUT Saving the last range we encountered > > Each subsequent call to the method retrieves the first record that has a > prefix with length prefix_length and which is different from cur_prefix, > @@ -11271,7 +11272,8 @@ int QUICK_RANGE_SELECT::get_next() > > int QUICK_RANGE_SELECT::get_next_prefix(uint prefix_length, > uint group_key_parts, > - uchar *cur_prefix) > + uchar *cur_prefix, > + QUICK_RANGE **save_last_range) > { > DBUG_ENTER("QUICK_RANGE_SELECT::get_next_prefix"); > const key_part_map keypart_map= make_prev_keypart_map(group_key_parts); > @@ -11301,8 +11303,43 @@ int QUICK_RANGE_SELECT::get_next_prefix(uint prefix_length, > last_range= 0; > DBUG_RETURN(HA_ERR_END_OF_FILE); > } > + > last_range= *(cur_range++); > > + /* > + While calculating these prefixes we might encounter a case where there > + woud be same partial ranges for multiple ranges. Typo. > + An example would be > + select max(f1), f2 from t1 where f2 ='c' AND f1 <> 9 group by f2; > + so the ranges would be > + (NULL,c <= f1,f2 <= c,9) > + (c,9 <= f1,f2 <= c,+infinity) This looks as if index was defined on (f1, f2) ? Then the comment doesn't make sense because loose index scan does not support queries in form: select max(key_part1) ... group by key_part2 It only can handle them when the index is on (f2,f1), but this is counterintuitive for the reader that is not familiar with the testcase for this bug. Please rephrase the comment. Please use key_part1 and key_part2 as column names. Tuple comparisons should look like this (note the braces): (a,b) < (c,d) . > + > + In this case for calculating prefixes with the group by field we take up the > + partial ranges involving field f2 those would be > + c<= f2 <=c > + c<= f2 <=c > + > + So we lookup rows with the same prefix in all such ranges and > + then we check for the other part(in this case f1) in ALL the ranges. > + So if a record lies in a range, then it would satisfy both the partial > + ranges in this case and therefore there would be multiple outputs for > + the same row. > + For such cases we should calculate the prefix only when we have the next > + partial range different from the previous one. > + */ > + > + > + if (*save_last_range) > + { > + if (!key_tuple_cmp(key_part_info, (*save_last_range)->min_key, > + last_range->min_key, prefix_length)) > + { > + last_range=NULL; > + continue; > + } > + } > + *save_last_range= last_range; > key_range start_key, end_key; > last_range->make_min_endpoint(&start_key, prefix_length, keypart_map); > last_range->make_max_endpoint(&end_key, prefix_length, keypart_map); > @@ -13315,7 +13352,7 @@ QUICK_GROUP_MIN_MAX_SELECT(TABLE *table, JOIN *join_arg, bool have_min_arg, > seen_first_key(FALSE), doing_key_read(FALSE), min_max_arg_part(min_max_arg_part_arg), > key_infix(key_infix_arg), key_infix_len(key_infix_len_arg), > min_functions_it(NULL), max_functions_it(NULL), > - is_index_scan(is_index_scan_arg) > + is_index_scan(is_index_scan_arg), save_last_range(NULL) This is not the right place for this initialization. It needs to be in QUICK_GROUP_MIN_MAX_SELECT::reset(), as the quick select may be executed multiple times. Testcase: create table ten(a int); insert into ten values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); MariaDB [test]> select (SELECT MAX(f1) as MAXVAL FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2) AS SUBQ from ten; +------+ | SUBQ | +------+ | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | +------+ 10 rows in set (0.00 sec) Now, let's add a HAVING clause (which always evaluates to TRUE but forces the subquery to be recomputed: MariaDB [test]> select (SELECT MAX(f1) as MAXVAL FROM t1 WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2 having maxval<100+ten.a) AS SUBQ from ten; +------+ | SUBQ | +------+ | 4 | | NULL | | NULL | | NULL | | NULL | | NULL | | NULL | | NULL | | NULL | | NULL | +------+ 10 rows in set (0.00 sec) To make sure this is loose index, try with IGNORE INDEX: MariaDB [test]> select (SELECT MAX(f1) as MAXVAL FROM t1 ignore index(f2) WHERE f2 LIKE 'c%' AND f1 <> 9 GROUP BY f2 having maxval<100+ten.a) AS SUBQ from ten; +------+ | SUBQ | +------+ | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | | 4 | +------+ 10 rows in set (0.00 sec) Please fix this and add the above into the testcase. > { > head= table; > index= use_index; > @@ -13968,7 +14005,8 @@ int QUICK_GROUP_MIN_MAX_SELECT::next_prefix() > uchar *cur_prefix= seen_first_key ? group_prefix : NULL; > if ((result= quick_prefix_select->get_next_prefix(group_prefix_len, > group_key_parts, > - cur_prefix))) > + cur_prefix, > + &save_last_range))) > DBUG_RETURN(result); > seen_first_key= TRUE; > } > diff --git a/sql/opt_range.h b/sql/opt_range.h > index b8b46ae5ab1..206d65f6da4 100644 > --- a/sql/opt_range.h > +++ b/sql/opt_range.h > @@ -477,7 +477,7 @@ class QUICK_RANGE_SELECT : public QUICK_SELECT_I > int get_next(); > void range_end(); > int get_next_prefix(uint prefix_length, uint group_key_parts, > - uchar *cur_prefix); > + uchar *cur_prefix, QUICK_RANGE **save_last_range); > bool reverse_sorted() { return 0; } > bool unique_key_range(); > int init_ror_merged_scan(bool reuse_handler, MEM_ROOT *alloc); > @@ -916,7 +916,8 @@ class QUICK_GROUP_MIN_MAX_SELECT : public QUICK_SELECT_I > Use index scan to get the next different key instead of jumping into it > through index read > */ > - bool is_index_scan; > + bool is_index_scan; > + QUICK_RANGE *save_last_range; Please add a comment describing the new member variable. > public: > /* > The following two members are public to allow easy access from BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

[Maria-developers] GSoC 2018 Student Self Introduction & Question
by zhzhzoo zhang 20 Mar '18

20 Mar '18

Hello everybody, I am a first year graduate in Peking University major in math. I started to take part in algorithm contests at grade 7 so I have a lot of programming experience and I am very well trained in algorithms and data structures. In my childhood memory MySQL was the most popular DBMS choice for personal website (LAMP stack). However it was acquired by Oracle as I grew up. In this year's GSoC projects, `optimizer trace' interested me particularly. It would be great for MariaDB to have this functionality. This functionality is already implemented in MySQL. So my question is, can I read MySQL's source code implementing this function? Would that cause legal problems? Thanks very much! Regards, Zhang Shuai.

3 2

Re: [Maria-developers] [Commits] a99dcdf7e9e: MDEV-6731: Valgrind warnings 'Invalid read' in subselect_engine::calc_const_tables with SQ in WHERE and
by Sergey Petrunia 16 Mar '18

16 Mar '18

Hi Varun, Please fix the MDEV# in the commit comment. Ok to push after that. On Wed, Mar 14, 2018 at 12:11:20PM +0530, Varun wrote: > revision-id: a99dcdf7e9ede3b96466eb1294284141805747fc (mariadb-10.0.30-308-ga99dcdf7e9e) > parent(s): 48c11d407b409a1291c84782518c69ee9138ce72 > author: Varun Gupta > committer: Varun Gupta > timestamp: 2018-03-14 12:09:49 +0530 > message: > > MDEV-6731: Valgrind warnings 'Invalid read' in subselect_engine::calc_const_tables with SQ in WHERE and > HAVING, ORDER BY, materialization+semijoin > > During cleanup a pointer to the materialised table that was freed was not set to NULL > > --- > mysql-test/r/having.result | 14 ++++++++++++++ > mysql-test/t/having.test | 18 ++++++++++++++++++ > sql/sql_select.cc | 4 +++- > 3 files changed, 35 insertions(+), 1 deletion(-) > > diff --git a/mysql-test/r/having.result b/mysql-test/r/having.result > index 0b933427303..99059c25fbd 100644 > --- a/mysql-test/r/having.result > +++ b/mysql-test/r/having.result > @@ -723,4 +723,18 @@ SELECT * FROM t1 JOIN t2 ON c1 = c2 HAVING c2 > 'a' ORDER BY c2 LIMIT 1; > c1 c2 > x x > DROP TABLE t1,t2; > +# > +# MDEV-6736: Valgrind warnings 'Invalid read' in subselect_engine::calc_const_tables with SQ > +# in WHERE and HAVING, ORDER BY, materialization+semijoin > +# > +CREATE TABLE t1 (a INT) ENGINE=MyISAM; > +INSERT INTO t1 VALUES (3),(8); > +CREATE TABLE t2 (b INT) ENGINE=MyISAM; > +INSERT INTO t2 VALUES (2),(1); > +SELECT a FROM t1 > +WHERE 9 IN ( SELECT MIN( a ) FROM t1 ) > +HAVING a <> ( SELECT COUNT(*) FROM t2 ) > +ORDER BY a; > +a > +DROP TABLE t1,t2; > End of 10.0 tests > diff --git a/mysql-test/t/having.test b/mysql-test/t/having.test > index 1682fe5b874..e624cd630dd 100644 > --- a/mysql-test/t/having.test > +++ b/mysql-test/t/having.test > @@ -759,4 +759,22 @@ SELECT * FROM t1 JOIN t2 ON c1 = c2 HAVING c2 > 'a' ORDER BY c2 LIMIT 1; > > DROP TABLE t1,t2; > > +--echo # > +--echo # MDEV-6736: Valgrind warnings 'Invalid read' in subselect_engine::calc_const_tables with SQ > +--echo # in WHERE and HAVING, ORDER BY, materialization+semijoin > +--echo # > + > +CREATE TABLE t1 (a INT) ENGINE=MyISAM; > +INSERT INTO t1 VALUES (3),(8); > + > +CREATE TABLE t2 (b INT) ENGINE=MyISAM; > +INSERT INTO t2 VALUES (2),(1); > + > +SELECT a FROM t1 > +WHERE 9 IN ( SELECT MIN( a ) FROM t1 ) > +HAVING a <> ( SELECT COUNT(*) FROM t2 ) > +ORDER BY a; > + > +DROP TABLE t1,t2; > + > --echo End of 10.0 tests > diff --git a/sql/sql_select.cc b/sql/sql_select.cc > index fd8ff6eb016..37d68c730dd 100644 > --- a/sql/sql_select.cc > +++ b/sql/sql_select.cc > @@ -11476,13 +11476,15 @@ void JOIN_TAB::cleanup() > } > else > { > + TABLE_LIST *tmp= table->pos_in_table_list; > end_read_record(&read_record); > - table->pos_in_table_list->jtbm_subselect->cleanup(); > + tmp->jtbm_subselect->cleanup(); > /* > The above call freed the materializedd temptable. Set it to NULL so > that we don't attempt to touch it if JOIN_TAB::cleanup() is invoked > multiple times (it may be) > */ > + tmp->table= NULL; > table=NULL; > } > DBUG_VOID_RETURN; > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] d8e3cfacebc: MDEV-14616: WSREP has not yet prepared node for application use error
by Sergei Golubchik 15 Mar '18

15 Mar '18

Hi, Jan! On Feb 13, jan wrote: > revision-id: d8e3cfacebc47849532ef3e7bbf18f9da53bab88 (mariadb-10.1.31-20-gd8e3cfacebc) > parent(s): 474f3df092cc73342b2da03aa03ba5c66930f596 > author: Jan Lindström > committer: Jan Lindström > timestamp: 2018-02-13 10:04:48 +0200 > message: > > MDEV-14616: WSREP has not yet prepared node for application use error > > Contains following Galera fixes: > > MW-405 Make sure wsrep is ready in wait_until_connected_again.inc What is "MW-405", can I see the original bug report somewhere? > wait_until_connected_again issues 'SHOW STATUS' query repeatedly > until mysqld replies without errors. However, SHOW STATUS is > treated specially by wsrep in that it is allowed to proceed > even if wsrep is not yet in ready state. As a consequence, > after returning from wait_until_connected_again, wsrep may > not be ready yet and subsequent queries may fail with error > "1047 WSREP has not yet prepared node for application use". > To avoid those errors, the patch includes > wait_wsrep_ready.inc at the end of the wait_until_connected_again.inc I don't quite understand the issue. Old code did wait_wsrep_ready.inc after wait_until_connected_again.inc. Now wait_wsrep_ready.inc is included in wait_until_connected_again.inc. This seems to imply that the bug was "there were some cases where wait_wsrep_ready.inc was not included after wait_until_connected_again.inc". There are, of course, two ways to fix such a bug. Either include wait_wsrep_ready.inc after wait_until_connected_again.inc, or include wait_wsrep_ready.inc in wait_until_connected_again.inc. The latter fix implies that there are no possible cases when one would want to wait for a server to be connected, but before wsrep is ready. Are there? For the purpose of testing, that could be useful, could it not? > kill_galera.inc can no longer rely on wait_until_connected_again.inc. > This is because wait_until_connected_again now tries to make sure > that the server it is connected eventually transition to ready state. > Whereas some tests may need to kill galera while the server is in a > non-primary view. Which means that there are cases when a test needs the server connected, but before wsrep is ready, right? > MW-408 Fix 'WSREP error while trying to determine node state' > > mysql-test-run.pl sporadically reports 'WSREP error while > trying to determine node state' right after starting servers > for test execution. This happens because we try to execute a > SELECT statement that queries the current value of status variable > wsrep_ready. If this statement fails, the above message is reported. > The failure is due to fact that wsrep may return error > ER_LOCK_WAIT_TIMEOUT (on any SELECT statement) if it is not ready > and wsrep_sync_wait enabled for SELECTs. The fix is to disable > wsrep_sync_wait for the session that issues those SELECT statements. 1. Could you put this fix in a separate commit please? 2. Sorry, I don't understand. Where do "we try to execute a SELECT statement that queries the current value of status variable wsrep_ready" ? > --- > mysql-test/include/restart_mysqld.inc | 3 - > mysql-test/include/start_mysqld.inc | 3 - > mysql-test/include/wait_until_connected_again.inc | 11 ++- > mysql-test/mysql-test-run.pl | 104 ++++++++++++++++++++++ > mysql-test/suite/galera/include/kill_galera.inc | 1 - > 5 files changed, 111 insertions(+), 11 deletions(-) > > diff --git a/mysql-test/include/restart_mysqld.inc b/mysql-test/include/restart_mysqld.inc > index a0447280ff5..940e081c431 100644 > --- a/mysql-test/include/restart_mysqld.inc > +++ b/mysql-test/include/restart_mysqld.inc > @@ -50,9 +50,6 @@ if (!$restart_parameters) > # Call script that will poll the server waiting for it to be back online again > --source include/wait_until_connected_again.inc > > -# Wait for wsrep > ---source include/wait_wsrep_ready.inc > - > # Turn off reconnect again > --disable_reconnect > > diff --git a/mysql-test/include/start_mysqld.inc b/mysql-test/include/start_mysqld.inc > index 04dff714d49..e31f26aad8c 100644 > --- a/mysql-test/include/start_mysqld.inc > +++ b/mysql-test/include/start_mysqld.inc > @@ -16,9 +16,6 @@ if (!$restart_parameters) > # Call script that will poll the server waiting for it to be back online again > --source include/wait_until_connected_again.inc > > -# Wait for wsrep > ---source include/wait_wsrep_ready.inc > - > # Turn off reconnect again > --disable_reconnect > > diff --git a/mysql-test/include/wait_until_connected_again.inc b/mysql-test/include/wait_until_connected_again.inc > index 6f64ef45440..4958d276ebd 100644 > --- a/mysql-test/include/wait_until_connected_again.inc > +++ b/mysql-test/include/wait_until_connected_again.inc > @@ -11,10 +11,7 @@ let $counter= 5000; > let $mysql_errno= 9999; > while ($mysql_errno) > { > - # Strangely enough, the server might return "Too many connections" > - # while being shutdown, thus 1040 is an "allowed" error > - # See BUG#36228 > - --error 0,1040,1053,2002,2003,2005,2006,2013,1927 > + --error 0,ER_SERVER_SHUTDOWN,ER_CONNECTION_KILLED,2002,2003,2006,2013 > show status; > > dec $counter; > @@ -26,3 +23,9 @@ while ($mysql_errno) > } > --enable_query_log > --enable_result_log > + > +# WSREP: SHOW STATUS queries are allowed even if wsrep > +# is not ready. Make sure wsrep is ready before > +# returning from this script > + > +--source include/wait_wsrep_ready.inc > diff --git a/mysql-test/mysql-test-run.pl b/mysql-test/mysql-test-run.pl > index eaec51b82b4..324f2e98ebd 100755 > --- a/mysql-test/mysql-test-run.pl > +++ b/mysql-test/mysql-test-run.pl > @@ -2883,6 +2883,49 @@ sub mysql_server_wait { > $warn_seconds); > } > > +sub have_wsrep() { > + my $wsrep_on= $mysqld_variables{'wsrep-on'}; > + return defined $wsrep_on > +} > + > + > +sub check_wsrep_support() { > + if (have_wsrep()) > + { > + mtr_report(" - binaries built with wsrep patch"); > + > + # ADD scripts to $PATH to that wsrep_sst_* can be found > + my ($path) = grep { -f "$_/wsrep_sst_rsync"; } "$::bindir/scripts", $::path_client_bindir; > + mtr_error("No SST scripts") unless $path; > + $ENV{PATH}="$path:$ENV{PATH}"; > + > + # Check whether WSREP_PROVIDER environment variable is set. > + if (defined $ENV{'WSREP_PROVIDER'}) { > + if ((mtr_file_exists($ENV{'WSREP_PROVIDER'}) eq "") && > + ($ENV{'WSREP_PROVIDER'} ne "none")) { > + mtr_error("WSREP_PROVIDER env set to an invalid path"); > + } > + # WSREP_PROVIDER is valid; set to a valid path or "none"). > + mtr_verbose("WSREP_PROVIDER env set to $ENV{'WSREP_PROVIDER'}"); > + } else { > + # WSREP_PROVIDER env not defined. Lets try to locate the wsrep provider > + # library. > + my $file_wsrep_provider= > + mtr_file_exists("/usr/lib/galera/libgalera_smm.so", > + "/usr/lib64/galera/libgalera_smm.so"); > + > + if ($file_wsrep_provider ne "") { > + # wsrep provider library found ! > + mtr_verbose("wsrep provider library found : $file_wsrep_provider"); > + $ENV{'WSREP_PROVIDER'}= $file_wsrep_provider; > + } else { > + mtr_verbose("Could not find wsrep provider library, setting it to 'none'"); > + $ENV{'WSREP_PROVIDER'}= "none"; > + } > + } > + } > +} > + > sub create_config_file_for_extern { > my %opts= > ( > @@ -3341,6 +3384,62 @@ sub run_query { > return $res > } > > +sub run_query_output { > + my ($mysqld, $query, $outfile)= @_; > + > + my $args; > + mtr_init_args(\$args); > + mtr_add_arg($args, "--defaults-file=%s", $path_config_file); > + mtr_add_arg($args, "--defaults-group-suffix=%s", $mysqld->after('mysqld')); > + > + mtr_add_arg($args, "--silent"); > + mtr_add_arg($args, "--execute=%s", $query); > + > + my $res= My::SafeProcess->run > + ( > + name => "run_query_output -> ".$mysqld->name(), > + path => $exe_mysql, > + args => \$args, > + output => $outfile, > + error => $outfile > + ); > + > + return $res > +} > + > +sub wait_wsrep_ready($$) { > + my ($tinfo, $mysqld)= @_; > + > + my $sleeptime= 100; # Milliseconds > + my $loops= ($opt_start_timeout * 1000) / $sleeptime; > + > + my $name= $mysqld->name(); > + my $outfile= "$opt_vardir/tmp/$name.wsrep_ready"; > + my $query= "SET SESSION wsrep_sync_wait = 0; > + SELECT VARIABLE_VALUE > + FROM INFORMATION_SCHEMA.GLOBAL_STATUS > + WHERE VARIABLE_NAME = 'wsrep_ready'"; > + > + for (my $loop= 1; $loop <= $loops; $loop++) > + { > + if (run_query_output($mysqld, $query, $outfile) != 0) > + { > + $tinfo->{logfile}= "WSREP error while trying to determine node state"; > + return 0; > + } > + > + if (mtr_grab_file($outfile) =~ /^ON/) > + { > + unlink($outfile); > + return 1; > + } > + > + mtr_milli_sleep($sleeptime); > + } > + > + $tinfo->{logfile}= "WSREP did not transition to state READY"; > + return 0; > +} > > sub do_before_run_mysqltest($) > { > @@ -5380,6 +5479,11 @@ sub start_servers($) { > $tinfo->{comment}= "Failed to start ".$_->name() . "\n"; > return 1; > } > + > + if (have_wsrep() && !wait_wsrep_ready($tinfo, $_)) > + { > + return 1; > + } > } > return 0; > } > diff --git a/mysql-test/suite/galera/include/kill_galera.inc b/mysql-test/suite/galera/include/kill_galera.inc > index c61bad8e19d..f95dccf2185 100644 > --- a/mysql-test/suite/galera/include/kill_galera.inc > +++ b/mysql-test/suite/galera/include/kill_galera.inc > @@ -18,4 +18,3 @@ > exit(0); > EOF > > ---source include/wait_until_disconnected.inc > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] dc3d6c9edb3: MDEV-15477: SESSION_SYSVARS_TRACKER does not track last_gtid
by Sergei Golubchik 09 Mar '18

09 Mar '18

Hi, Oleksandr! On Mar 09, Oleksandr Byelkin wrote: > revision-id: dc3d6c9edb3536e5f0c87ac1e9c04891d50fc420 (mariadb-10.2.13-32-gdc3d6c9edb3) > parent(s): 6cf25e5eb76923550173a0059036d80c80a053d6 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2018-03-09 14:39:40 +0100 > message: > > MDEV-15477: SESSION_SYSVARS_TRACKER does not track last_gtid > > register changes of last_gtid > > diff --git a/mysql-test/t/session_tracker_last_gtid.test b/mysql-test/t/session_tracker_last_gtid.test > --- /dev/null > +++ b/mysql-test/t/session_tracker_last_gtid.test > @@ -0,0 +1,18 @@ > + > +--source include/have_innodb.inc > +--source include/have_binlog_format_mixed_or_statement.inc Why "mixed or statement"? > diff --git a/sql/log.cc b/sql/log.cc > --- a/sql/log.cc > +++ b/sql/log.cc > @@ -5945,7 +5945,20 @@ MYSQL_BIN_LOG::write_gtid_event(THD *thd, bool standalone, > } > if (err) > DBUG_RETURN(true); > + bool changed_gtid= (thd->last_commit_gtid.seq_no != gtid.seq_no); > thd->last_commit_gtid= gtid; > + if (changed_gtid && > + thd->session_tracker.get_tracker(SESSION_SYSVARS_TRACKER)->is_enabled()) > + { > + sys_var *svar; > + mysql_mutex_lock(&LOCK_plugin); > + if ((svar= find_sys_var_ex(thd, "last_gtid", > + sizeof("last_gtid") - 1, > + false, true))) > + thd->session_tracker.get_tracker(SESSION_SYSVARS_TRACKER)-> > + mark_as_changed(thd, (LEX_CSTRING*)svar); > + mysql_mutex_unlock(&LOCK_plugin); > + } No, please. You svar will always be Sys_last_gtid. There is no need to search for it on every write_gtid_event(), under a mutex. See in sys_vars.cc around Sys_autocommit how to do it easier. Also, perhaps it'd be safer to rename last_commit_gtid to m_last_commit_gtid, make it private and provide a setter and a getter. The setter will update the tracker. I'll make sure that last_commit_gtid is not changed anywhere else bypassing the tracker. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] 6cf25e5eb76: Session tracking info support in mysqltest
by Sergei Golubchik 09 Mar '18

09 Mar '18

Hi, Oleksandr! On Mar 09, Oleksandr Byelkin wrote: > revision-id: 6cf25e5eb76923550173a0059036d80c80a053d6 (mariadb-10.2.13-31-g6cf25e5eb76) > parent(s): f2b91c878cf4ec53c292caba7f5907d1ef724de4 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2018-03-09 14:27:13 +0100 > message: > > Session tracking info support in mysqltest Add a test case for it. Don't forget to test whether ONCE modifier works. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] f2b91c878cf: Reset connection support in mysqltest
by Sergei Golubchik 09 Mar '18

09 Mar '18

Hi, Oleksandr! On Mar 09, Oleksandr Byelkin wrote: > revision-id: f2b91c878cf4ec53c292caba7f5907d1ef724de4 (mariadb-10.2.13-30-gf2b91c878cf) > parent(s): 8f98835bb86550a68a6c412d8417cc169dfdc206 > author: Oleksandr Byelkin > committer: Oleksandr Byelkin > timestamp: 2018-03-09 14:26:10 +0100 > message: > > Reset connection support in mysqltest You add a feature - add a test case for it too. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

[Maria-developers] MariaDB 5.5, Jemalloc, TokuDB, RHEL
by Michal Schorm 08 Mar '18

08 Mar '18

Hello, so far we packed MariaDB 5.5 for RHEL 7 without TokuDB and without Jemalloc. Recently, a customer asked about the availability of TokuDB, so I'm doing a research, if its possible to pack it without any issues for the users updating. I have a several questions: 1) Is Jemmaloc used elsewhere from TokuDB ? 2) If yes, what all would be affected? Could any issues arise during update from build without Jemalloc to build with it? Any expected performance changes? 3) Would be the use of the bundled Jemalloc (on of the) best option(s)? 4) Anything else that I missed? -- Michal Schorm Associate Software Engineer Core Services - Databases Team Red Hat

2 1

[Maria-developers] Introduction as GSoC 2018 aspirant
by Arshdeep Singh Sachdeva 05 Mar '18

05 Mar '18

Dear MariaDB Developers, I am Arshdeep Singh Sachdeva, currently studying BTech ( C.S.E. ) from Punjab Engineering College, Chandigarh, India. I am interested in contibuting to MariaDB and participating in GSoC 2018 under your guidance. I am proficient in C++, python, linux, mysql. I have already used MariaDB in my projects in college. Also I am presently going through documentation and tutorials. Thanks.

1 0