July 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] 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

[Maria-developers] MDEV-8372 Use helper methods introduced in MDEV-7824 all around the code
by Alexander Barkov 11 Sep '15

11 Sep '15

Hi Sergei, Please review my patch for mdev-8372. I found only a few places to reuse the new methods. Also, had to add some more helper methods to make the code clearer. Thanks.

2 3

Re: [Maria-developers] 3eceb51: MDEV-7990: ERROR 1526 when procedure executed for second time ALTER TABLE partition ... pMAX values less than MAXVALUE
by Sergei Golubchik 05 Aug '15

05 Aug '15

Hi, Sanja! On May 06, sanja(a)mariadb.com wrote: > revision-id: 3eceb51e697d5a514e70c374a06e7eef6b5a37a0 > parent(s): aa5095627e2619bdad7916d33d1016802a84a9e1 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-05-06 13:19:22 +0200 > message: > > MDEV-7990: ERROR 1526 when procedure executed for second time ALTER > TABLE partition ... pMAX values less than MAXVALUE > > Added cleaning partition data which are saved in LEX structure to make > possible correct re-execution of a SP or PS using the code. No, this is wrong. See prep_alter_part_table(). The first thing it does it to copy thd->lex->part_info to thd->work_part_info. It tries to do a deep copy to be able to modify it freely, but apparently the copy isn't deep enough. I see two options 1. Do a deeper copy. Duplicate all value lists. 2. Make part_column_list_val elements immutable. That would be preferred, of course, but I'm not sure it's possible. Regards, Sergei

2 2

Re: [Maria-developers] [Commits] 2430d1d: MDEV-7821 - Server crashes in Item_func_group_concat::fix_fields on 2nd
by Oleksandr Byelkin 31 Jul '15

31 Jul '15

Hi! On 30.07.15 16:59, Sergey Vojtovich wrote: > revision-id: 2430d1d7ccfcf429e45dbfe655a24d57a79ebf6c (mariadb-5.5.44-14-g2430d1d) > parent(s): 392df76bc3a40a5dd1956b12628dd6489a37be36 > committer: Sergey Vojtovich > timestamp: 2015-07-30 18:51:44 +0400 > message: > > MDEV-7821 - Server crashes in Item_func_group_concat::fix_fields on 2nd > execution of PS > > GROUP_CONCAT() with ORDER BY column position may crash server on PS reexecution. > > The problem was that arguments array of GROUP_CONCAT() was adjusted to point to > temporary elements (resolved ORDER BY fields) during first execution. > > This patch expands rev. 08763096cb to restore original arguments array as well. OK to push! > > --- > mysql-test/r/func_gconcat.result | 16 ++++++++++++++++ > mysql-test/t/func_gconcat.test | 11 +++++++++++ > sql/item_sum.cc | 3 +++ > 3 files changed, 30 insertions(+) > > diff --git a/mysql-test/r/func_gconcat.result b/mysql-test/r/func_gconcat.result > index f12a0c1..0bc31a5 100644 > --- a/mysql-test/r/func_gconcat.result > +++ b/mysql-test/r/func_gconcat.result > @@ -1103,3 +1103,19 @@ ORDER BY field; > field > c,c > drop table t3, t2, t1; > +# > +# MDEV-7821 - Server crashes in Item_func_group_concat::fix_fields on 2nd > +# execution of PS > +# > +CREATE TABLE t1(a INT); > +INSERT INTO t1 VALUES(1),(2); > +PREPARE stmt FROM "SELECT GROUP_CONCAT(t1a.a ORDER BY 1, t1a.a=0) FROM t1 AS t1a, t1 AS t1b GROUP BY t1a.a"; > +EXECUTE stmt; > +GROUP_CONCAT(t1a.a ORDER BY 1, t1a.a=0) > +1,1 > +2,2 > +EXECUTE stmt; > +GROUP_CONCAT(t1a.a ORDER BY 1, t1a.a=0) > +1,1 > +2,2 > +DROP TABLE t1; > diff --git a/mysql-test/t/func_gconcat.test b/mysql-test/t/func_gconcat.test > index 42a3076..5550eeb 100644 > --- a/mysql-test/t/func_gconcat.test > +++ b/mysql-test/t/func_gconcat.test > @@ -821,3 +821,14 @@ FROM ( SELECT * FROM t2 ) AS sq2, t3 > ORDER BY field; > > drop table t3, t2, t1; > + > +--echo # > +--echo # MDEV-7821 - Server crashes in Item_func_group_concat::fix_fields on 2nd > +--echo # execution of PS > +--echo # > +CREATE TABLE t1(a INT); > +INSERT INTO t1 VALUES(1),(2); > +PREPARE stmt FROM "SELECT GROUP_CONCAT(t1a.a ORDER BY 1, t1a.a=0) FROM t1 AS t1a, t1 AS t1b GROUP BY t1a.a"; > +EXECUTE stmt; > +EXECUTE stmt; > +DROP TABLE t1; > diff --git a/sql/item_sum.cc b/sql/item_sum.cc > index d8970ca..a24307b 100644 > --- a/sql/item_sum.cc > +++ b/sql/item_sum.cc > @@ -3300,6 +3300,8 @@ void Item_func_group_concat::cleanup() > from Item_func_group_concat::setup() to point to runtime > created objects, we need to reset them back to the original > arguments of the function. > + > + The very same applies to args array. > */ > ORDER **order_ptr= order; > for (uint i= 0; i < arg_count_order; i++) > @@ -3307,6 +3309,7 @@ void Item_func_group_concat::cleanup() > (*order_ptr)->item= &args[arg_count_field + i]; > order_ptr++; > } > + memcpy(args, orig_args, sizeof(Item *) * arg_count); > DBUG_VOID_RETURN; > } > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

1 0

[Maria-developers] [MDEV-8554] Weird behavior of multi-table UPDATE and THD::save_prep_leaf_list
by Sergey Petrunia 30 Jul '15

30 Jul '15

Hello Igor, I was debugging https://mariadb.atlassian.net/browse/MDEV-8554 The patch is about save_prep_leaf_list is not being cleaned up by a statement. I committed a patch that makes that bug go away. However, the way that statements work with THD::save_prep_leaf_list look weird to me. Since it was you who added save_prep_leaf_list, I wanted to ask you: Consider an example: CREATE TABLE t1 (a INT) ENGINE=MyISAM; INSERT INTO t1 VALUES (1),(2); # Not necessary, the table can be empty CREATE TABLE t2 (b INT) ENGINE=MyISAM; INSERT INTO t2 VALUES (3),(4); # Not necessary, the table can be empty CREATE TABLE t3 (c INT) ENGINE=MyISAM; INSERT INTO t3 VALUES (5),(6); # Not necessary, the table can be empty CREATE OR REPLACE ALGORITHM=MERGE VIEW v3 AS SELECT * FROM t3; Now, let's debug how THD::save_prep_leaf_list changes and is used: UPDATE t1, t2 SET a = 1 WHERE a IN ( SELECT 0 FROM v3 ); We see: 1. Breakpoint 4, THD::THD (this=0x59ff6f0) at /home/psergey/dev-git/10.0/sql/sql_class.cc:1062 save_prep_leaf_list= FALSE; 2. Breakpoint 1, THD::reset_for_next_command (this=0x59ff6f0) at /home/psergey/dev-git/10.0/sql/sql_parse.cc:6272 thd->save_prep_leaf_list= false; ^^^ I have added this line in my fix 3. Breakpoint 5, LEX::save_prep_leaf_tables (this=0x5a02f80) at /home/psergey/dev-git/10.0/sql/sql_lex.cc:4132 bool LEX::save_prep_leaf_tables() { if (!thd->save_prep_leaf_list) return FALSE; ^^^ This is where save_prep_leaf_list is used. 4. Breakpoint 2, mysql_derived_merge (thd=0x59ff6f0, lex=0x5a02f80, derived=0x7fff68008618) at /home/psergey/dev-git/10.0/sql/sql_derived.cc:379 if (thd->lex->sql_command == SQLCOM_UPDATE_MULTI || thd->lex->sql_command == SQLCOM_DELETE_MULTI) thd->save_prep_leaf_list= TRUE; ^^^ this is where save_prep_leaf_list is changed by this statement. 5. (no break). The statement finished. That is, the statement first checks save_prep_leaf_list, and then uses it. This looks weird. Any thoughts? BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

1 0

Re: [Maria-developers] 9f8a458: MDEV-7846: Server crashes in Item_subselect::fix_fields or fails with Thread stack overrun
by Sergei Golubchik 30 Jul '15

30 Jul '15

Hi, Sanja! On Apr 23, sanja(a)mariadb.com wrote: > revision-id: 9f8a458fb2d07298810bb5d9824ce728017bfb32 > parent(s): e540d023e2ec6f37efc9ab695ccdfd4a6744ad64 > committer: Oleksandr Byelkin > branch nick: server > timestamp: 2015-04-23 20:08:57 +0200 > message: > > MDEV-7846: Server crashes in Item_subselect::fix_fields or fails with > Thread stack overrun > > Substitute into transformed subselects original left expression and > than register its change in case it was substituted. Looks mostly ok to me. But please: 1. Add comments (the patch is attached) 2. Add a test case with row items 3. In your test case - if you remove GROUP BY you get a crash again. This might be a different bug, though. Regards, Sergei

1 0

[Maria-developers] mysql_stmt_prepare_start returns with error code 2006
by András Szabó 29 Jul '15

29 Jul '15

Hi Folks, I am currently working on a c++11 asio based async connector for mariadb. The library takes advantage of mariadb’s async interface (mysql_*_start, mysql_*_cont functions). The whole point would be to prevent blocking in mysql operations and make operations cancellable via a reasonable interface. Some example code: TEST_CASE("tmp3") { init_db(); asio::io_service io; amdb::connector conn(io); bool saved = false; entity e(42, 3.14, "our entity"); amdb::auth_info auth("root"); conn.async_connect(amdb::null_endpoint, "edbtest", auth, amdb::default_flags, [&] (const std::error_code& ec) { REQUIRE(!ec); conn.async_write_entity(e, [&] (const std::error_code &ec) { INFO(ec); REQUIRE(!ec); if (!ec) { saved = true; } io.stop(); }); }); io.run(); REQUIRE(saved); } async_write_entity() is an extra feature of the lib, which is generating an sql “batch” of prepared statements to persist hierarchical objects and executes that batch. Unfortunately I am receiving an error 2006 from my very first mysql_stmt_prepare call. This error roughly translates to "connection to mysql server is gone”. I cannot really spot the issue with my operation, could someone give me a hint about this error (typical causes, what to check, etc etc.)? I am a bit clueless here how to tackle this problem. Since the batch generation/execution code is a bit convoluted and complex, i would not paste it here now, but if someone can point me in the right direction i can share relevant parts. Thanks in advance Andras -- András Szabó Sent with Airmail

2 2

Re: [Maria-developers] 4728581: MDEV-7652 - More explanatory ERROR and WARNING messages when loading plugins
by Sergei Golubchik 29 Jul '15

29 Jul '15

Hi, Sergey! Looks ok, just a couple of comments about the messages. If you're agree - please, fix and push. On Jul 28, Sergey Vojtovich wrote: > revision-id: 4728581813000522d05ab589df8e5f8cb6ad1ee6 > parent(s): cf30074c3ff6815d85bbd864b28adfe7949d340c > committer: Sergey Vojtovich > branch nick: mariadb Please, update the git post-commit hook (bzr-pull from mariadb-tools). I've just changed it to report a branch better than just "mariadb". > timestamp: 2015-07-28 10:18:55 +0400 > message: > > MDEV-7652 - More explanatory ERROR and WARNING messages when loading plugins > with plugin-load-add that are already registered at mysql.plugin > > - issue just one error message, without this extra warning > - don't abuse ER_UDF_EXISTS, instead add a proper error message for plugins > - report started initialization for each plugin source > > --- > sql/share/errmsg-utf8.txt | 3 +++ > sql/sql_plugin.cc | 15 +++++++++++---- > 2 files changed, 14 insertions(+), 4 deletions(-) > > diff --git a/sql/share/errmsg-utf8.txt b/sql/share/errmsg-utf8.txt > index 6954170..374e31f 100644 > --- a/sql/share/errmsg-utf8.txt > +++ b/sql/share/errmsg-utf8.txt > @@ -7111,3 +7111,6 @@ 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_TABLE_DEFINITION_TOO_BIG > eng "The definition for table %`s is too big" > +ER_PLUGIN_EXISTS > + eng "Plugin '%-.192s' already exists" > + rus "Плагин '%-.192s' уже существует" May be "already installed" ? The command is INSTALL PLUGIN. For UDF it was CREATE FUNCTION, that's why "already exists", I suppose. > diff --git a/sql/sql_plugin.cc b/sql/sql_plugin.cc > index dc40870..21efeb0 100644 > --- a/sql/sql_plugin.cc > +++ b/sql/sql_plugin.cc > @@ -1546,6 +1546,9 @@ int plugin_init(int *argc, char **argv, int flags) > /* > First we register builtin plugins > */ > + if (global_system_variables.log_warnings >= 9) > + sql_print_information("Initializing mandatory plugins"); > + > for (builtins= mysql_mandatory_plugins; *builtins || mandatory; builtins++) > { > if (!*builtins) Here you should've put "Initializing optional plugins". Actually, a better message would be "Initializing other built-in plugins" or " Initializing remaining built-in plugins". > @@ -1627,11 +1630,17 @@ int plugin_init(int *argc, char **argv, int flags) > { > I_List_iterator<i_string> iter(opt_plugin_load_list); > i_string *item; > + if (global_system_variables.log_warnings >= 9) > + sql_print_information("Initializinig plugins specified by command line"); "Initializinig plugins specified on the command line" > while (NULL != (item= iter++)) > plugin_load_list(&tmp_root, item->ptr); > > if (!(flags & PLUGIN_INIT_SKIP_PLUGIN_TABLE)) > + { > + if (global_system_variables.log_warnings >= 9) > + sql_print_information("Initializing installed plugins"); > plugin_load(&tmp_root); > + } > } Regards, Sergei

2 2

[Maria-developers] Using oqgraph/connect engines in mariadb-galera-server
by Nirbhay Choubey 28 Jul '15

28 Jul '15

Hi Serg, Svoj! I am looking into an issue where accessing oqgraph/connect engines from galera server leads to errors like "Unknown option '<table option>'" and segfaults. The issue being the differences in handlerton structure in galera and non-galera server codes. Since the connect/oqgraph packages are built from non-galera server, when they are loaded into galera server, the engine's handlerton gets improperly initialized. https://mariadb.atlassian.net/browse/MDEV-8240 I can think of the following potential solutions : a) Club connect/oqgraph and mariadb-galera-server into a single package. (this would mean adding new dependencies to mariadb-galera-server) b) New packages for connect/oqgraph out of mariadb-galera build (mariadb-connect-engine-galera-10.0, mariadb-oqgraph-engine-galera-10.0) Do you see any other option? Also, we should add some checks for plugin load to fail in first place in such scenarios. Best, Nirbhay

2 1