September 2015 - developers - lists.mariadb.org

[Maria-developers] Super Read Only in MariaDB (10.1) ?
by Jean-François Gagné 19 Sep '15

19 Sep '15

Hi, a super_read_only option is making its way in MySQL 5.7: * http://www.tocker.ca/2015/07/09/mysql-5-7-8-now-featuring-super_read_only-a… * http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_… Are there plans to have a similar option in MariaDB (it would be great to have it in MariaDB 10.1) ? Many thanks, -- Jean-François Gagné System Engineer Booking.com BV Rembrandt Square Office Herengracht 597, 1017 CE Amsterdam

2 1

[Maria-developers] New programmer
by Acha Bill 18 Sep '15

18 Sep '15

Hello guys, I'm Acha Bill. Final year undergraduate in Computer Engineering. I would like to be an active contributor to your ongoing projects. I have good knowledge of C/C++ and MySQL. As this is my first approach to open source, any guidance will be much appreciated. Bill.

3 3

Re: [Maria-developers] Please review MDEV-8468 MDEV-8466
by Sergei Golubchik 17 Sep '15

17 Sep '15

Hi, Alexander! On Jul 21, Alexander Barkov wrote: > > I have one question about "HANDLER FOR SQLWARNING". > It does not catch messages of level "Note". > Looks like a bug. Please confirm, I'll file a report if so. Hmm, I don't know. According to the standard, SQLWARNING should match sqlstates in the category W, while SQLEXCEPTION should be for sqlstates in the category X. But we don't do that, 22007 is an exception (category X), but we treat it as a warning. So, the standard doesn't help to answer your question. We seem to use the logic where a level "error" means an SQL exception and a level "warning" means an SQL warning. Using this logic, "notes" are neither exceptions nor warnings, and neither SQLEXCEPTION nor SQLWARNING should match them. I'd say it's not a bug. The patch itself looks great, these changes in behavior are very welcomed. Just one small comment regarding THD::check_edom_and_truncation(), see below. > diff --git a/sql/sql_class.h b/sql/sql_class.h > index a8d8444..c19174b 100644 > --- a/sql/sql_class.h > +++ b/sql/sql_class.h > @@ -3270,6 +3270,53 @@ class THD :public Statement, > (!transaction.stmt.modified_non_trans_table || > (variables.sql_mode & MODE_STRICT_ALL_TABLES))); > } > + /** > + Check string-to-number conversion and produce a warning if > + - could not convert any digits (EDOM-alike error) > + - found garbage at the end of the string > + See also Field_num::check_edom_and_truncation() for a similar function. > + > + @param thd - the thread > + @param type - name of the data type (e.g. "INTEGER", "DECIMAL", "DOUBLE") > + @param edom - of a EDOM-alike error happened > + @param cs - character set of the original string > + @param str - the original string > + @param end_of_num - the position where the string-to-number routine stopped. > + @param end - the end of the string > + > + Unlike Field_num::check_edom_and_truncation(), this function does not > + distinguish between EDOM and truncation and reports the same warning for > + both cases. Perhaps we should eventually print different warnings, to make > + the explicit CAST work closer to the implicit cast in Field_xxx::store(). Why haven't you done it now? It causes too many changes in tests? > + */ > + void check_edom_and_truncation(const char *type, bool edom, > + CHARSET_INFO *cs, > + const char *str, > + const char *end_of_num, > + const char *end) Move this out of THD please. You don't need to call current_thd every time for it, but only when a warning should be issued. > + { > + DBUG_ASSERT(str <= end_of_num); > + DBUG_ASSERT(end_of_num <= end); > + if (edom || > + (end_of_num < end && !check_if_only_end_space(cs, end_of_num, end))) > + { > + /* > + We can use err.ptr() here as ErrConvString is guranteed to put an > + end \0 here. > + */ > + push_warning_printf(this, Sql_condition::WARN_LEVEL_WARN, > + ER_TRUNCATED_WRONG_VALUE, > + ER(ER_TRUNCATED_WRONG_VALUE), type, > + ErrConvString(str, end - str, cs).ptr()); > + } > + else if (end_of_num < end) > + { > + push_warning_printf(this, Sql_condition::WARN_LEVEL_NOTE, > + ER_TRUNCATED_WRONG_VALUE, > + ER(ER_TRUNCATED_WRONG_VALUE), type, > + ErrConvString(str, end - str, cs).ptr()); > + } > + } Regards, Sergei

2 1

[Maria-developers] unsubscribe
by Abdul Hakeem 16 Sep '15

16 Sep '15

1 0

Re: [Maria-developers] [Commits] a1f31cf: MDEV-6756: map a linux pid (child pid) to a connection id shown in the output of SHOW PROCESSLIST
by Sergei Golubchik 16 Sep '15

16 Sep '15

Hi, Sanja! Looks good, thanks. Ok to push! On Sep 15, sanja(a)mariadb.com wrote: > revision-id: a1f31cfa8d0f04cb166813786f7854db3dbcf715 (mariadb-10.1.6-12-ga1f31cf) > parent(s): 86a3613d4e981c341e38291c9eeec5dc9f836fae > committer: Oleksandr Byelkin > timestamp: 2015-09-15 21:50:28 +0200 > message: > > MDEV-6756: map a linux pid (child pid) to a connection id shown in the > output of SHOW PROCESSLIST > > Added tid (thread ID) for system where it is present. > > ps -eL -o tid,pid,command > > shows the thread on Linux Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 8bf23ef: MDEV-8208: Sporadic SEGFAULT on startup
by Sergei Golubchik 16 Sep '15

16 Sep '15

Hi, Nirbhay! On Aug 19, Nirbhay Choubey wrote: > revision-id: 8bf23efc914f18c687067e9314cadf4f36a85eec > parent(s): 71d1f35847a575239deff856590bf6f13afd74ed > committer: Nirbhay Choubey > branch nick: 5.5-galera.b8208 > timestamp: 2015-08-19 17:17:56 -0400 > message: > > MDEV-8208: Sporadic SEGFAULT on startup A couple of questions: > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index 2008fc5..4c05999 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -4584,6 +4579,29 @@ static int init_server_components() > } > plugins_are_initialized= TRUE; /* Don't separate from init function */ > > +#ifdef WITH_WSREP > + /* Wait for wsrep threads to get created. */ > + if (wsrep_creating_startup_threads == 1) { > + mysql_mutex_lock(&LOCK_thread_count); > + while (wsrep_running_threads < 2) > + { > + mysql_cond_wait(&COND_thread_count, &LOCK_thread_count); > + } > + > + /* Now is the time to initialize threads for queries. */ > + THD *tmp; > + I_List_iterator<THD> it(threads); > + while ((tmp= it++)) > + if (tmp->wsrep_applier == true) > + tmp->init_for_queries(); Do you really need to iterate over all THD's? There is only one applier thread, right? And it's THD is not stored anywhere, only in the global list? > + mysql_mutex_unlock(&LOCK_thread_count); > + } > +#endif > + > have_csv= plugin_status(STRING_WITH_LEN("csv"), > MYSQL_STORAGE_ENGINE_PLUGIN); > have_ndbcluster= plugin_status(STRING_WITH_LEN("ndbcluster"), > @@ -4890,12 +4902,21 @@ pthread_handler_t start_wsrep_THD(void *arg) > //thd->version= refresh_version; > thd->proc_info= 0; > thd->command= COM_SLEEP; > - thd->set_time(); > - thd->init_for_queries(); > + > + if (plugins_are_initialized) > + { > + thd->init_for_queries(); > + } What happens if plugins are not initialized yet? thd->init_for_queries() will be done in that THD loop above? In that case why do you need to do it here? Regards, Sergei

2 2

Re: [Maria-developers] [Commits] 6ed7307: MDEV-8576: Bootstrap should ignore --enforce-storage-engine option
by Sergei Golubchik 16 Sep '15

16 Sep '15

Hi, Jan! On Sep 16, Jan Lindström wrote: > revision-id: 6ed73070e120e1be5456288556019db5bd3f9f60 > parent(s): 6cc1befcf26b2dc43e5cd7ad85d29c576073b1c5 > committer: Jan Lindström > branch nick: 10.1-tests > timestamp: 2015-09-16 11:47:34 +0300 > message: > > MDEV-8576: Bootstrap should ignore --enforce-storage-engine option > > Allow enforce-storage-engine="" option and use that on mysql_install_db > when doing bootstrap. Agree. After I commented on the previous patch it occurred to me that --disable-enforce-storage-engine is a bad idea, because --enable-enforce-storage-engine makes no sense, and one normally expects --enable-xxx for every --disable-xxx. So --enforce-storage-engine="" is a better way of switching this feature off. > diff --git a/sql/mysqld.cc b/sql/mysqld.cc > index b45d4e1..ee3b870 100644 > --- a/sql/mysqld.cc > +++ b/sql/mysqld.cc > @@ -4843,7 +4843,10 @@ static void add_file_to_crash_report(char *file) > static int init_default_storage_engine_impl(const char *opt_name, > char *engine_name, plugin_ref *res) > { > - if (!engine_name) > + /* Storage engine can be NULL and enforced storage engine > + can be empty. */ > + if (!engine_name || > + (strcmp(opt_name, "enforced_storage_engine") == 0 && strlen(engine_name) == 0)) > { > *res= 0; > return 0; In fact, default_tmp_storage_engine can be NULL too. See in mysqld.cc: if (default_tmp_storage_engine && !*default_tmp_storage_engine) default_tmp_storage_engine= NULL; if (init_default_storage_engine(default_tmp_storage_engine, tmp_table_plugin)) unireg_abort(1); And it looks like it's important to have default_tmp_storage_engine=NULL, not leave it as an empty string. Because Sys_var_plugin::do_check() doesn't allow empty strings as plugins names, but translates NULL to "no plugin". So, you either need to set enforced_storage_engine=NULL if it was an empty string, or you need to fix Sys_var_plugin::do_check() to treat empty strings as "no plugin" too. Regards, Sergei

1 0

Re: [Maria-developers] [Commits] 7f7cbb1: MDEV-6756: map a linux pid (child pid) to a connection id shown in the output of SHOW PROCESSLIST
by Sergei Golubchik 15 Sep '15

15 Sep '15

Hi, Sanja! There's an issue with cmake detection and with tests. But the code looks fine, thanks! On Sep 14, sanja(a)mariadb.com wrote: > revision-id: 7f7cbb132fa0a40687e4b25a9c9e163c93ec6d15 (mariadb-10.1.6-12-g7f7cbb1) > parent(s): 86a3613d4e981c341e38291c9eeec5dc9f836fae > committer: Oleksandr Byelkin > timestamp: 2015-09-14 12:47:57 +0200 > message: > > MDEV-6756: map a linux pid (child pid) to a connection id shown in the > output of SHOW PROCESSLIST > > Added tid (thread ID) for system where it is present. > > ps -eL -o tid,pid,command > > shows the thread on Linux > > diff --git a/mysql-test/r/information_schema.result b/mysql-test/r/information_schema.result > index 2a918ad..ef889c7 100644 > --- a/mysql-test/r/information_schema.result > +++ b/mysql-test/r/information_schema.result > @@ -2066,3 +2066,7 @@ Variable_name Value > Opened_tables 3 > drop database mysqltest; > drop database db1; > +set @TID= (SELECT tid FROM information_schema.processlist); > +select (SELECT tid FROM information_schema.processlist) = @TID; > +(SELECT tid FROM information_schema.processlist) = @TID > +1 That seems pretty useless as a test :) > diff --git a/sql/sql_class.cc b/sql/sql_class.cc > index bf161b2..0478b33 100644 > --- a/sql/sql_class.cc > +++ b/sql/sql_class.cc > @@ -69,6 +69,10 @@ > #include "sql_connect.h" > #include "my_atomic.h" > > +#ifdef HAVE_SYS_SYSCALL_H Pardon me? Did you see whether your code actually work? You check here whether HAVE_SYS_SYSCALL_H is defined, but you don't have CHECK_INCLUDE_FILES(sys/syscall.h HAVE_SYS_SYSCALL_H) in configure.cmake and HAVE_SYS_SYSCALL_H in config.h.cmake. So, I don't see how your code can possibly work as HAVE_SYS_SYSCALL_H should be never defined in your patch. Please, when fixing it, make sure that your test *fails* without TID support (I suspect you'll have to enable it only on linux). And then you could remove that useless test above. > +#include <sys/syscall.h> > +#endif Regards, Sergei

2 2

[Maria-developers] MDEV-3929 Add system variable explicit_defaults_for_timestamp for compatibility with MySQL
by Alexander Barkov 15 Sep '15

15 Sep '15

Hi Sergei, Please review a patch that merges a new read-only variables --explicit-defaults-for-timestamp from MySQL. Note, the original MySQL patch updates many tests, to make the tests independent from the compiled-in default --explicit-defaults-for-timestamp value. I guess Oracle is planning to change the default value to ON eventually. I merged these changes for tests as well. As a result, all tests pass in both "mtr" and "mtr --mysqld=--explicit-defaults-for-timestamp", which I think is good. In addition to the original MySQL changes in mtr, I also added two tests that describe specific behavior: sys_vars.explicit_defaults_for_timestamp_off sys_vars.explicit_defaults_for_timestamp_on Note, the patch assumes that the server and the slave have the same --explicit-defaults-for-timeatamp. Monty suggested to make this variable dynamic and replication-safe. We added a separate task for this: MDEV-8455 Make --explicit-defaults-for-timestamp dynamic I plan to do it in the next 10.1 sprint round. Thanks.

2 8

Re: [Maria-developers] [Commits] 8983790: MDEV-7970: EXPLAIN FORMAT=JSON does not print HAVING
by Oleksandr Byelkin 14 Sep '15

14 Sep '15

On 14.09.15 21:59, Sergey Petrunia wrote: > Hi Sanja, > > The big comment: I see HAVING being printed for EXPLAIN FORMAT=JSON but not for > ANALYZE FORMAT=JSON. > > For example: > > MariaDB [test]> explain format=json select count(*) from t1 where t1.a between 0 and 1000 group by b having count(*) > 0\G > *************************** 1. row *************************** > EXPLAIN: { > "query_block": { > "select_id": 1, > "having_condition": "(count(0) > 0)", > "filesort": { > "temporary_table": { > "function": "buffer", > "table": { > "table_name": "t1", > "access_type": "ALL", > "rows": 1000, > "filtered": 100, > "attached_condition": "(t1.a between 0 and 1000)" > } > } > } > } > } > > MariaDB [test]> analyze format=json select count(*) from t1 where t1.a between 0 and 1000 group by b having count(*) > 0\G > *************************** 1. row *************************** > ANALYZE: { > "query_block": { > "select_id": 1, > "r_loops": 1, > "r_total_time_ms": 49.417, > "filesort": { > "r_loops": 1, > "r_total_time_ms": 0.4251, > "r_used_priority_queue": false, > "r_output_rows": 101, > "r_buffer_size": "2Kb", > "temporary_table": { > "table": { > "table_name": "t1", > "access_type": "ALL", > "r_loops": 1, > "rows": 1000, > "r_rows": 1000, > "r_total_time_ms": 18.597, > "filtered": 100, > "r_filtered": 100, > "attached_condition": "(t1.a between 0 and 1000)" > } > } > } > } > } oops, I'll fix. > > Smaller comments below. > > On Wed, Sep 09, 2015 at 04:29:54PM +0200, sanja(a)mariadb.com wrote: >> revision-id: 8983790df9a16520e69905fc4c35d20f7c935c3e (mariadb-10.1.6-119-g8983790) >> parent(s): 3fcd84c2891f4d2c881f13b53bc5a2401870b80a >> committer: Oleksandr Byelkin >> timestamp: 2015-09-09 16:29:50 +0200 >> message: >> >> MDEV-7970: EXPLAIN FORMAT=JSON does not print HAVING >> >> Printing non-trivial HAVING added. >> >> --- >> mysql-test/r/explain_json.result | 84 ++++++++++++++++++++++++++++++++++++++++ >> mysql-test/t/explain_json.test | 23 ++++++++++- >> sql/sql_explain.cc | 15 ++++++- >> sql/sql_explain.h | 7 +++- >> sql/sql_select.cc | 2 + >> 5 files changed, 128 insertions(+), 3 deletions(-) >> >> diff --git a/mysql-test/r/explain_json.result b/mysql-test/r/explain_json.result >> index 0507cee..db2726d 100644 >> --- a/mysql-test/r/explain_json.result >> +++ b/mysql-test/r/explain_json.result >> @@ -799,6 +799,7 @@ EXPLAIN >> { >> "query_block": { >> "select_id": 2, >> + "having_condition": "trigcond(<is_not_null_test>(t1.a))", >> "full-scan-on-null_key": { >> "table": { >> "table_name": "t1", >> @@ -1070,3 +1071,86 @@ EXPLAIN >> } >> } >> drop table t1; >> +# >> +# MDEV-7970: EXPLAIN FORMAT=JSON does not print HAVING >> +# >> +create table t0(a int); >> +insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); >> +create table t1(a int); >> +insert into t1 select A.a + B.a* 10 + C.a * 100 from t0 A, t0 B, t0 C; >> +create table t2 ( >> +a int, >> +b int, >> +key (a) >> +); >> +insert into t2 select A.a*1000 + B.a, A.a*1000 + B.a from t0 A, t1 B; >> +# normal HAVING >> +explain format=json select a, max(b) as TOP from t2 group by a having TOP > a; >> +EXPLAIN >> +{ >> + "query_block": { >> + "select_id": 1, >> + "having_condition": "(TOP > t2.a)", >> + "filesort": { >> + "temporary_table": { >> + "function": "buffer", >> + "table": { >> + "table_name": "t2", >> + "access_type": "ALL", >> + "rows": 10000, >> + "filtered": 100 >> + } >> + } >> + } >> + } >> +} >> +# HAVING is always TRUE (not printed) >> +explain format=json select a, max(b) as TOP from t2 group by a having 1<>2; >> +EXPLAIN >> +{ >> + "query_block": { >> + "select_id": 1, >> + "filesort": { >> + "temporary_table": { >> + "function": "buffer", >> + "table": { >> + "table_name": "t2", >> + "access_type": "ALL", >> + "rows": 10000, >> + "filtered": 100 >> + } >> + } >> + } >> + } >> +} >> +# HAVING is always FALSE (intercepted by message) >> +explain format=json select a, max(b) as TOP from t2 group by a having 1=2; >> +EXPLAIN >> +{ >> + "query_block": { >> + "select_id": 1, >> + "table": { >> + "message": "Impossible HAVING" >> + } >> + } >> +} >> +# HAVING is absent >> +explain format=json select a, max(b) as TOP from t2 group by a; >> +EXPLAIN >> +{ >> + "query_block": { >> + "select_id": 1, >> + "filesort": { >> + "temporary_table": { >> + "function": "buffer", >> + "table": { >> + "table_name": "t2", >> + "access_type": "ALL", >> + "rows": 10000, >> + "filtered": 100 >> + } >> + } >> + } >> + } >> +} >> +drop table t0, t1, t2; >> diff --git a/mysql-test/t/explain_json.test b/mysql-test/t/explain_json.test >> index 3e6f34b..0870817 100644 >> --- a/mysql-test/t/explain_json.test >> +++ b/mysql-test/t/explain_json.test >> @@ -278,4 +278,25 @@ explain format=json select count(distinct a1,a2,b,c) from t1 where (a2 >= 'b') a >> >> drop table t1; >> >> - >> +--echo # >> +--echo # MDEV-7970: EXPLAIN FORMAT=JSON does not print HAVING >> +--echo # >> +create table t0(a int); >> +insert into t0 values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9); >> +create table t1(a int); >> +insert into t1 select A.a + B.a* 10 + C.a * 100 from t0 A, t0 B, t0 C; >> +create table t2 ( >> + a int, >> + b int, >> + key (a) >> +); >> +insert into t2 select A.a*1000 + B.a, A.a*1000 + B.a from t0 A, t1 B; > This seems to be excessive. I don't see any examples using key(a), I don't see a need to > populate a table with 1M rows. I was not the man who made the test suite, usually sotuation is reverse somebody require to keep the original. But I agree, I'll fix. >> +--echo # normal HAVING >> +explain format=json select a, max(b) as TOP from t2 group by a having TOP > a; >> +--echo # HAVING is always TRUE (not printed) >> +explain format=json select a, max(b) as TOP from t2 group by a having 1<>2; >> +--echo # HAVING is always FALSE (intercepted by message) >> +explain format=json select a, max(b) as TOP from t2 group by a having 1=2; >> +--echo # HAVING is absent >> +explain format=json select a, max(b) as TOP from t2 group by a; >> +drop table t0, t1, t2; >> diff --git a/sql/sql_explain.cc b/sql/sql_explain.cc >> index 15ee67a..5f60aee 100644 >> --- a/sql/sql_explain.cc >> +++ b/sql/sql_explain.cc >> @@ -862,7 +862,20 @@ void Explain_select::print_explain_json(Explain_query *query, >> writer->add_member("const_condition"); >> write_item(writer, exec_const_cond); >> } >> - >> + /* we do not print always TRUE HAVING */ > This doesn't parse. Did you mean: > " Do not print HAVING clause if it always evaluates to TRUE" ? yes > >> + if (having || (having_value == Item::COND_FALSE)) >> + { >> + writer->add_member("having_condition"); >> + if (likely(having)) >> + write_item(writer, having); >> + else >> + { >> + /* Normally we should not go this branch, left just for safety */ >> + DBUG_ASSERT(having_value == Item::COND_FALSE); >> + writer->add_str("0"); >> + } >> + } >> + >> Filesort_tracker *first_table_sort= NULL; >> bool first_table_sort_used= false; >> int started_objects= 0; >> diff --git a/sql/sql_explain.h b/sql/sql_explain.h >> index f92a576..434be47 100644 >> --- a/sql/sql_explain.h >> +++ b/sql/sql_explain.h >> @@ -209,6 +209,7 @@ class Explain_select : public Explain_basic_join >> Explain_select(MEM_ROOT *root, bool is_analyze) : >> Explain_basic_join(root), >> message(NULL), >> + having(NULL), having_value(Item::COND_UNDEF), >> using_temporary(false), using_filesort(false), >> time_tracker(is_analyze), >> ops_tracker(is_analyze) >> @@ -231,7 +232,11 @@ class Explain_select : public Explain_basic_join >> >> /* Expensive constant condition */ >> Item *exec_const_cond; >> - >> + >> + /* HAVING condition */ >> + COND *having; >> + Item::cond_result having_value; >> + >> /* Global join attributes. In tabular form, they are printed on the first row */ >> bool using_temporary; >> bool using_filesort; >> diff --git a/sql/sql_select.cc b/sql/sql_select.cc >> index 3f2c2ea..be4b076 100644 >> --- a/sql/sql_select.cc >> +++ b/sql/sql_select.cc >> @@ -24159,6 +24159,8 @@ int JOIN::save_explain_data_intern(Explain_query *output, bool need_tmp_table, >> xpl_sel->using_filesort= true; >> >> xpl_sel->exec_const_cond= exec_const_cond; >> + xpl_sel->having= having; >> + xpl_sel->having_value= having_value; >> >> JOIN_TAB* const first_top_tab= join->first_breadth_first_optimization_tab(); >> JOIN_TAB* prev_bush_root_tab= NULL; > BR > Sergei

1 0