- developers - lists.mariadb.org

Re: [Maria-developers] [Commits] 787610a: MDEV-10766: Queries which start with WITH clause do not get inserted into query cache
by Sergey Petrunia 04 Feb '17

04 Feb '17

Hi Varun, On Fri, Feb 03, 2017 at 08:20:51PM +0530, Varun wrote: > revision-id: 787610a1f5cec04311fd16f6c1de87171e5cfdd4 (mariadb-10.2.3-159-g787610a) > parent(s): bc12d993d7bc94a9533028a258afc7e4ceb21e92 > author: Varun Gupta > committer: Varun Gupta > timestamp: 2017-02-03 20:17:16 +0530 > message: > > MDEV-10766: Queries which start with WITH clause do not get inserted into query cache > > Added conditions so that the WITH queries are also added to the query cache > > --- > mysql-test/r/query_cache.result | 30 ++++++++++++++++++++++++++++++ > mysql-test/t/query_cache.test | 14 ++++++++++++++ > sql/sql_cache.cc | 5 ++++- > 3 files changed, 48 insertions(+), 1 deletion(-) > > diff --git a/mysql-test/r/query_cache.result b/mysql-test/r/query_cache.result > index d34c96c..fa169d4 100644 > --- a/mysql-test/r/query_cache.result > +++ b/mysql-test/r/query_cache.result > @@ -2136,6 +2136,36 @@ Qcache_hits 1 > use test; > drop database `foo.bar`; > End of 10.0 tests > +FLUSH USER_STATISTICS; > +FLUSH CLIENT_STATISTICS; I'm wondering what is the reason for the above? Qcache_XXX status variables are flushed with FLUSH STATUS. > +flush status; > +show status like "Qcache_inserts"; > +Variable_name Value > +Qcache_inserts 0 > +create table t1 (i int); > +with cte as (select * from t1) select * from cte; > +i > +show status like "Qcache_queries_in_cache"; > +Variable_name Value > +Qcache_queries_in_cache 1 > +show status like "Qcache_inserts"; > +Variable_name Value > +Qcache_inserts 1 > +show status like "Qcache_hits"; > +Variable_name Value > +Qcache_hits 0 > +with cte as (select * from t1) select * from cte; > +i > +show status like "Qcache_queries_in_cache"; > +Variable_name Value > +Qcache_queries_in_cache 1 > +show status like "Qcache_inserts"; > +Variable_name Value > +Qcache_inserts 1 > +show status like "Qcache_hits"; > +Variable_name Value > +Qcache_hits 1 > +drop table t1; > restore defaults > SET GLOBAL query_cache_type= default; > SET GLOBAL query_cache_size= default; BR Sergei -- Sergei Petrunia, Software Developer MariaDB Corporation | Skype: sergefp | Blog: http://s.petrunia.net/blog

2 1

[Maria-developers] the patch for mdev-9976 broke some tests
by Alexander Barkov 01 Feb '17

01 Feb '17

Hello Igor, These tests fails in 10.2 due to ROWS now being a reserved word: binlog_encryption.binlog_write_error rpl.rpl_killed_ddl binlog.binlog_write_error Can you please fix this? Thanks!

1 0

[Maria-developers] MDEV-10142 - bb-10.2-compatibility
by jerome brauge 01 Feb '17

01 Feb '17

Hello, To build this branch on windows (Visual Studio Express 2015), I have to add "#pragma warning( disable : 4099 )" in sql_lex.h. But I don't know if it's the right solution. I have some questions: - I read the comment of Michael Widenius on subtask MDEV-10574. I think that it's important to change behavior of string functions whose returns a string (like rtrim, ltrim, substring, concat, ...) to return null instead of ''. Without this, we have to use UDF instead native functions and it's never good from a performance point of view. Have you made a decision ? - On Oracle, we can easily disable/enable triggers. I found an old request for this on jira : MDEV-7579. As you already manage order_action now, perhaps you can simply use negative orders to indicate disabled triggers. - do you have planning to implement operator || to concat strings ? Best regards, J. Brauge

3 16

[Maria-developers] valgrind + SSL
by Alexander Barkov 01 Feb '17

01 Feb '17

Hello Elena, You wrote on IRC: On 01/31/2017 08:10 PM, Slack wrote: > bar: hi! We have this in 10.0 valgrind, what do you think about it? > http://buildbot.askmonty.org/buildbot/builders/work-amd64-valgrind/builds/9… > > i'm asking you because you fixed a similar-looking problem once: > https://jira.mariadb.org/browse/MDEV-4890 I'm not very familiar with this part. But IIUC, two things could happen: - Somebody changed the code in mysqld.cc, so the SSL cleanup routines do not get called correctly any more. - Somebody is wrong inside the library itself. When did this problem first appear? After some commit? Or after the SSQL library update/change on the build box? Is it specific to 10.0? When I was fixing MDEV-4890, I fixed both: - added some cleanup function calls - added the second SSL suppression The problem was reproducible on my box. Now I cannot reproduce the problem on my box. I tried: cmake . -DCMAKE_BUILD_TYPE=Debug -DWITH_VALGRIND=1 ./mtr --valgrind binlog.binlog_max_extension ./mtr --valgrind federated.error_on_close-8313 ./mtr --valgrind rpl.rpl_old_master Note, we have these valgrind suppressions: > { > OpenSSL still reachable. > Memcheck:Leak > fun:*alloc > fun:CRYPTO_malloc > fun:sk_new > obj:*libssl* > fun:SSL_COMP_get_compression_methods > fun:SSL_library_init > } > > > { > OpenSSL still reachable. > Memcheck:Leak > fun:*alloc > fun:CRYPTO_malloc > obj:*libssl* > fun:SSL_COMP_get_compression_methods > fun:SSL_library_init > } Do you know why the problem does not get suppressed? Perhaps we should try to remove "obj:*libssl*" ? But before doing this it would be nice to know when the problem first appeared.

1 0

Re: [Maria-developers] Please review MDEV-9979 Keywords UNBOUNDED, PRECEDING, FOLLOWING, TIES, OTHERS should be non-reserved
by Vicențiu Ciorbaru 31 Jan '17

31 Jan '17

Hi Alexander, OK to push. Please add the version of the standard you used to check these keywords as non-reserved both to the commit message, as well as the keywords themselves. I used 2011 standard draft to check. Vicențiu On Mon, 23 Jan 2017 at 09:28 Alexander Barkov <bar(a)mariadb.com> wrote: > Hello Vicențiu, > > Can you please review a patch for MDEV-9979. > > Thanks! >

2 1

[Maria-developers] Please review MDEV-11692 Comparison data type aggregation for pluggable data types
by Alexander Barkov 31 Jan '17

31 Jan '17

Hello Vicențiu, can you please review a patch for MDEV-11692. The patch is for bb-10.2-ext. Thanks!

2 1

Re: [Maria-developers] [Commits] ef590fa: MDEV-7409 On RBR, extend the PROCESSLIST info to include at least the name of the recently used table
by Daniel Black 31 Jan '17

31 Jan '17

On 24/01/17 04:30, SachinSetiya wrote: > revision-id: ef590faa0e21d25a2dc5153f938135612b17ecbc (mariadb-10.1.20-31-gef590fa) > thd_proc_info(thd, message); > + DBUG_EXECUTE_IF("should_sleep_for_mdev7409",{ > + my_sleep(500000); > + };); Shouldn't these be DEBUG_SYNC_C("do_exec_row"); and then use debug_sync to generate test synchronisation. > int error= write_row(rgi, slave_exec_mode == SLAVE_EXEC_MODE_IDEMPOTENT); > thd_proc_info(thd, tmp); > + thd->db= tmp_db; > > if (error && !thd->is_error()) > { > @@ -12371,32 +12380,45 @@ int Delete_rows_log_event::do_exec_row(rpl_group_info *rgi) > { > int error; > const char *tmp= thd->get_proc_info(); > - const char *message= "Delete_rows_log_event::find_row()"; > + char *tmp_db= thd->db; > + char *message, msg[128]; > + my_snprintf(msg, sizeof(msg),"Delete_rows_log_event::find_row() on table %s", > + m_table->s->table_name.str); > + thd->db= m_table->s->db.str; > + message= msg; Why assign a pointer? Isn't defining message as a char[128] sufficient? Thanks for writing this feature.

3 3

Re: [Maria-developers] [Commits] d44c14e: MDEV-10812 WSREP causes responses being sent to protocol commands that must not send a response
by Nirbhay Choubey 30 Jan '17

30 Jan '17

Hi Sachin! On Fri, Jan 27, 2017 at 12:53 AM, SachinSetiya <sachin.setiya(a)mariadb.com> wrote: > revision-id: d44c14e1e0dea312779ba0a8633583ee94284295 > (mariadb-10.1.21-2-gd44c14e) > parent(s): a14638581b4c8ef175e68dccff07967d819b3b7e > author: Sachin Setiya > committer: Sachin Setiya > timestamp: 2017-01-27 11:23:17 +0530 > message: > > MDEV-10812 WSREP causes responses being sent to protocol commands that > must not send a response > > Problem:- When using wsrep (w/ galera) and issuing commands that can cause > deadlocks, deadlock exception errors are sent in responses to commands > such as close prepared statement and close connection which, by spec, must > not send a > In commit message, we normally limit line width to 60 chars. > response. > > Solution:- In dispatch_command, we will handle COM_QUIT and COM_STMT_CLOSE > commands even in case of error. I think you forgot to add the patch credit you had in previous commits. > --- > mysql-test/suite/galera/r/galera_mdev_10812.result | 11 +++++++++ > mysql-test/suite/galera/t/galera_mdev_10812.test | 27 > ++++++++++++++++++++++ > sql/sql_parse.cc | 10 +++++++- > 3 files changed, 47 insertions(+), 1 deletion(-) > > diff --git a/mysql-test/suite/galera/r/galera_mdev_10812.result > b/mysql-test/suite/galera/r/galera_mdev_10812.result > new file mode 100644 > index 0000000..fba1000 > --- /dev/null > +++ b/mysql-test/suite/galera/r/galera_mdev_10812.result > @@ -0,0 +1,11 @@ > +# > +# MDEV-10812: On COM_STMT_CLOSE/COM_QUIT, when wsrep_conflict_state > +# is ABORTED, it causes wrong response to be sent to the client > +# > +SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; > +CREATE TABLE t1(a INT PRIMARY KEY); > +INSERT INTO t1 VALUES(1),(2),(3); > +START TRANSACTION ; > +UPDATE t1 SET a=a+100; > +UPDATE t1 SET a=a+100; > +DROP TABLE t1; > diff --git a/mysql-test/suite/galera/t/galera_mdev_10812.test > b/mysql-test/suite/galera/t/galera_mdev_10812.test > new file mode 100644 > index 0000000..4539ab6 > --- /dev/null > +++ b/mysql-test/suite/galera/t/galera_mdev_10812.test > @@ -0,0 +1,27 @@ > +--source include/galera_cluster.inc > +--source include/have_innodb.inc > + > +--echo # > +--echo # MDEV-10812: On COM_STMT_CLOSE/COM_QUIT, when wsrep_conflict_state > +--echo # is ABORTED, it causes wrong response to be sent to the client > +--echo # > + > +# First create a deadlock > +--connect node_1a, 127.0.0.1, root, , test, $NODE_MYPORT_1 > +SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; > +CREATE TABLE t1(a INT PRIMARY KEY); > +INSERT INTO t1 VALUES(1),(2),(3); > +START TRANSACTION ; > +UPDATE t1 SET a=a+100; > + > +--sleep 2 > +--connection node_2 > +UPDATE t1 SET a=a+100; > + > +--sleep 2 > +--connection node_1a > +# here we get deadlock error > +--disconnect node_1a > + > +--connection node_2 > +DROP TABLE t1; > diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc > index 033e88a..cb0bd41 100644 > --- a/sql/sql_parse.cc > +++ b/sql/sql_parse.cc > @@ -1265,7 +1265,9 @@ bool dispatch_command(enum enum_server_command > command, THD *thd, > { > wsrep_client_rollback(thd); > } > - if (thd->wsrep_conflict_state== ABORTED) > + /* We let COM_QUIT and COM_STMT_CLOSE to execute even if wsrep > aborted. */ > + if (thd->wsrep_conflict_state == ABORTED && > + command != COM_STMT_CLOSE && command != COM_QUIT) > { > my_error(ER_LOCK_DEADLOCK, MYF(0), "wsrep aborted transaction"); > WSREP_DEBUG("Deadlock error for: %s", thd->query()); > @@ -1918,6 +1920,12 @@ bool dispatch_command(enum enum_server_command > command, THD *thd, > > if (WSREP(thd)) > { > + /* > + MDEV-10812 > + In the case of COM_QUIT/COM_CLOSE thread status should be disabled. > s/COM_CLOSE/COM_STMT_CLOSE/ > + */ > + DBUG_ASSERT((command != COM_QUIT && command != COM_STMT_CLOSE) > + || thd->get_stmt_da()->is_disabled()); > Could you check the indentation of the above line? Considering above changes, I have no more suggestions. Ok to push. Best, Nirbhay > /* wsrep BF abort in query exec phase */ > mysql_mutex_lock(&thd->LOCK_wsrep_thd); > do_end_of_statement= thd->wsrep_conflict_state != REPLAYING && > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits

2 2

[Maria-developers] 10.2 branch is locked down
by Sergei Golubchik 29 Jan '17

29 Jan '17

Hi, 10.2 branch has recently become quite red in buildbot. Eventually we'll be implementing something to prevent it in the future, but for now we've simply locked it down to prevent further pushes. If you want to push make sure you push into a stage branch first, then this stage branch should be green or at least it should fix at least some of test failures from the main 10.2. Then either send an email or ping on irc or create a pull request and we'll add you to the list of people who can push. At the moment this list is empty. When 10.2 is green again, we'll remove this protection. Regards, Sergei Chief Architect MariaDB and security(a)mariadb.org

1 0

Re: [Maria-developers] [Commits] 5190ebd: MDEV-11817: Altering a table with more rows than ..
by Sachin Setiya 29 Jan '17

29 Jan '17

Hi Nirbhay! On Tue, Jan 24, 2017 at 8:02 AM, Nirbhay Choubey <nirbhay(a)mariadb.com> wrote: > > revision-id: 5190ebde3aa142219e1c703df6ea1a78f171182c (mariadb-10.1.21-7-g5190ebd) > parent(s): 15f46d517435f3570e2c788349637a06d818a619 > author: Nirbhay Choubey > committer: Nirbhay Choubey > timestamp: 2017-01-23 21:32:50 -0500 > message: > > MDEV-11817: Altering a table with more rows than .. > > .. wsrep_max_ws_rows causes cluster to break when running > Galera cluster in TOI mode > > During ALTER TABLE, while copying records to temporary > table, since the records are not placed into the binary > log, wsrep_affected_rows must also not be incremented. > I think, you should write a more detailed commit message, So that user/developer can link this commit to jira task body. May be add something like this Problem:- 1. When doing altering table in galera cluster if table has more records than wsrep_max_ws_rows it gives error. 2. Doing this also breaks replication. Solution:- 1. Your commit message. 2. Replication is broke because setting up wsrep_max_ws_rows is not transferred to another cluster. And as ALTER command is passed in statement format and it is passed much earlier. here in Sql_cmd_alter_table::execute(THD *thd) function. #ifdef WITH_WSREP TABLE *find_temporary_table(THD *thd, const TABLE_LIST *tl); if ((!thd->is_current_stmt_binlog_format_row() || !find_temporary_table(thd, first_table))) { WSREP_TO_ISOLATION_BEGIN(((lex->name.str) ? select_lex->db : NULL), ((lex->name.str) ? lex->name.str : NULL), first_table); } this send alter command to another node , before it is executed on node. Galera assumes that if alter command is failed on one node it should also be failing on other nodes. Or may be this can be added in comment. > > --- > .../suite/galera/r/galera_var_max_ws_rows.result | 23 ++++++++ > .../suite/galera/t/galera_var_max_ws_rows.test | 28 +++++++++- > sql/handler.cc | 61 ++++++++++++---------- > 3 files changed, 83 insertions(+), 29 deletions(-) > > diff --git a/mysql-test/suite/galera/r/galera_var_max_ws_rows.result b/mysql-test/suite/galera/r/galera_var_max_ws_rows.result > index 6e239c7..555bd1a 100644 > --- a/mysql-test/suite/galera/r/galera_var_max_ws_rows.result > +++ b/mysql-test/suite/galera/r/galera_var_max_ws_rows.result > @@ -113,3 +113,26 @@ INSERT INTO t1 (f2) VALUES (2); > ERROR HY000: wsrep_max_ws_rows exceeded > DROP TABLE t1; > DROP TABLE ten; > +# > +# MDEV-11817: Altering a table with more rows than > +# wsrep_max_ws_rows causes cluster to break when running > +# Galera cluster in TOI mode > +# > +CREATE TABLE t1(c1 INT)ENGINE = INNODB; > +SET GLOBAL wsrep_max_ws_rows= DEFAULT; > +INSERT INTO t1 VALUES(1); > +INSERT INTO t1 SELECT * FROM t1; > +INSERT INTO t1 SELECT * FROM t1; > +INSERT INTO t1 SELECT * FROM t1; > +INSERT INTO t1 SELECT * FROM t1; > +SET GLOBAL wsrep_max_ws_rows= 10; > +ALTER TABLE t1 CHANGE COLUMN c1 c1 BIGINT; > +SHOW CREATE TABLE t1; > +Table Create Table > +t1 CREATE TABLE `t1` ( > + `c1` bigint(20) DEFAULT NULL > +) ENGINE=InnoDB DEFAULT CHARSET=latin1 > +SELECT COUNT(*) FROM t1; > +COUNT(*) > +16 > +DROP TABLE t1; > diff --git a/mysql-test/suite/galera/t/galera_var_max_ws_rows.test b/mysql-test/suite/galera/t/galera_var_max_ws_rows.test > index 944238b..4b2ba60 100644 > --- a/mysql-test/suite/galera/t/galera_var_max_ws_rows.test > +++ b/mysql-test/suite/galera/t/galera_var_max_ws_rows.test > @@ -146,10 +146,34 @@ INSERT INTO t1 (f2) VALUES (1); > --error ER_ERROR_DURING_COMMIT > INSERT INTO t1 (f2) VALUES (2); > > +DROP TABLE t1; > +DROP TABLE ten; > + > +--echo # > +--echo # MDEV-11817: Altering a table with more rows than > +--echo # wsrep_max_ws_rows causes cluster to break when running > +--echo # Galera cluster in TOI mode > +--echo # > +--connection node_1 > +CREATE TABLE t1(c1 INT)ENGINE = INNODB; > +SET GLOBAL wsrep_max_ws_rows= DEFAULT; > +INSERT INTO t1 VALUES(1); > +INSERT INTO t1 SELECT * FROM t1; > +INSERT INTO t1 SELECT * FROM t1; > +INSERT INTO t1 SELECT * FROM t1; > +INSERT INTO t1 SELECT * FROM t1; > +SET GLOBAL wsrep_max_ws_rows= 10; > +ALTER TABLE t1 CHANGE COLUMN c1 c1 BIGINT; > + > +--connection node_2 > +SHOW CREATE TABLE t1; > +SELECT COUNT(*) FROM t1; > +DROP TABLE t1; > + > +--connection node_1 > > --disable_query_log > --eval SET GLOBAL wsrep_max_ws_rows = $wsrep_max_ws_rows_orig > --enable_query_log > > -DROP TABLE t1; > -DROP TABLE ten; > +--source include/galera_end.inc > diff --git a/sql/handler.cc b/sql/handler.cc > index af06427..48946de 100644 > --- a/sql/handler.cc > +++ b/sql/handler.cc > @@ -5724,6 +5724,30 @@ static int write_locked_table_maps(THD *thd) > } > > > +static int check_wsrep_max_ws_rows() > +{ > +#ifdef WITH_WSREP > + if (wsrep_max_ws_rows) > + { > + THD *thd= current_thd; > + > + if (!WSREP(thd)) > + return 0; > + > + thd->wsrep_affected_rows++; > + if (thd->wsrep_exec_mode != REPL_RECV && > + thd->wsrep_affected_rows > wsrep_max_ws_rows) > + { > + trans_rollback_stmt(thd) || trans_rollback(thd); > + my_message(ER_ERROR_DURING_COMMIT, "wsrep_max_ws_rows exceeded", MYF(0)); > + return ER_ERROR_DURING_COMMIT; > + } > + } > +#endif /* WITH_WSREP */ > + return 0; > +} > + > + I think declaring check_wsrep_max_ws_rows() on top would be a much better option. > typedef bool Log_func(THD*, TABLE*, bool, const uchar*, const uchar*); > > static int binlog_log_row(TABLE* table, > @@ -5765,6 +5789,13 @@ static int binlog_log_row(TABLE* table, > bool const has_trans= thd->lex->sql_command == SQLCOM_CREATE_TABLE || > table->file->has_transactions(); > error= (*log_func)(thd, table, has_trans, before_record, after_record); > + > + /* > + Now that the record has been logged, increment wsrep_affected_rows and > + also check whether its within the allowable limits (wsrep_max_ws_rows). > + */ > + if (error == 0) > + error= check_wsrep_max_ws_rows(); > } > } > return error ? HA_ERR_RBR_LOGGING_FAILED : 0; > @@ -5875,30 +5906,6 @@ int handler::ha_reset() > } > > > -static int check_wsrep_max_ws_rows() > -{ > -#ifdef WITH_WSREP > - if (wsrep_max_ws_rows) > - { > - THD *thd= current_thd; > - > - if (!WSREP(thd)) > - return 0; > - > - thd->wsrep_affected_rows++; > - if (thd->wsrep_exec_mode != REPL_RECV && > - thd->wsrep_affected_rows > wsrep_max_ws_rows) > - { > - trans_rollback_stmt(thd) || trans_rollback(thd); > - my_message(ER_ERROR_DURING_COMMIT, "wsrep_max_ws_rows exceeded", MYF(0)); > - return ER_ERROR_DURING_COMMIT; > - } > - } > -#endif /* WITH_WSREP */ > - return 0; > -} > - > - > int handler::ha_write_row(uchar *buf) > { > int error; > @@ -5923,7 +5930,7 @@ int handler::ha_write_row(uchar *buf) > DBUG_RETURN(error); /* purecov: inspected */ > > DEBUG_SYNC_C("ha_write_row_end"); > - DBUG_RETURN(check_wsrep_max_ws_rows()); > + DBUG_RETURN(0); > } > > > @@ -5954,7 +5961,7 @@ int handler::ha_update_row(const uchar *old_data, uchar *new_data) > rows_changed++; > if (unlikely(error= binlog_log_row(table, old_data, new_data, log_func))) > return error; > - return check_wsrep_max_ws_rows(); > + return 0; > } > > int handler::ha_delete_row(const uchar *buf) > @@ -5981,7 +5988,7 @@ int handler::ha_delete_row(const uchar *buf) > rows_changed++; > if (unlikely(error= binlog_log_row(table, buf, 0, log_func))) > return error; > - return check_wsrep_max_ws_rows(); > + return 0; > } > > > _______________________________________________ > commits mailing list > commits(a)mariadb.org > https://lists.askmonty.org/cgi-bin/mailman/listinfo/commits -- Regards Sachin Setiya Software Engineer at MariaDB

2 2