- developers - lists.mariadb.org

[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

[Maria-developers] Fwd: [Commits] d1124c9: MDEV-10812 WSREP causes responses being sent to protocol commands that must not send a response
by Sachin Setiya 27 Jan '17

27 Jan '17

Hi Nirbhay! On Wed, Jan 25, 2017 at 7:53 PM, Nirbhay Choubey <nirbhay(a)mariadb.com> wrote: > Hi Sachin, > > My comments below. > > On Sun, Jan 22, 2017 at 7:18 AM, SachinSetiya <sachin.setiya(a)mariadb.com> > wrote: >> >> revision-id: d1124c98cbede6366e4b4d27a23dcf5b9d207cf0 >> (mariadb-10.1.21-2-gd1124c9) >> parent(s): a14638581b4c8ef175e68dccff07967d819b3b7e >> author: Sachin Setiya >> committer: Sachin Setiya >> timestamp: 2017-01-22 17:47:29 +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 () which, by spec, must not send a > > > s/close prepared statement ()/close prepared statement and close connection/ > >> response. >> >> Solution:- We will not jump to dispatch_end: when there is deadlock and >> query is either COM_QUIT or COM_STMT_CLOSE. > > > Or, I would say, in dispatch_command, we handle COM_QUIT and COM_STMT_CLOSE > commands even in case of error. Changed. > >> >> >> Patch Credit:- Jaka Močnik >> >> --- >> .../galera/r/galera_prepared_statement.result | 18 ++++++++++++++++ >> .../suite/galera/t/galera_prepared_statement.test | 25 >> ++++++++++++++++++++++ >> sql/sql_parse.cc | 6 +++++- >> 3 files changed, 48 insertions(+), 1 deletion(-) >> >> diff --git a/mysql-test/suite/galera/r/galera_prepared_statement.result >> b/mysql-test/suite/galera/r/galera_prepared_statement.result >> index de5ac9c..3425648 100644 >> --- a/mysql-test/suite/galera/r/galera_prepared_statement.result >> +++ b/mysql-test/suite/galera/r/galera_prepared_statement.result >> @@ -27,7 +27,25 @@ ALTER TABLE t1 ADD COLUMN f2 INTEGER; >> ALTER TABLE t1 DROP COLUMN f1; >> EXECUTE st1; >> ERROR 22007: Incorrect integer value: 'abc' for column 'f2' at row 1 >> +SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; >> +CREATE TABLE t5(a int primary key); >> +INSERT INTO t5 VALUES(1),(2),(3); >> +START TRANSACTION ; >> +PREPARE st5 FROM 'SELECT * FROM t5'; >> +EXECUTE st5; >> +a >> +1 >> +2 >> +3 >> +update t5 set a=a+100; >> +EXECUTE st5; >> +a >> +101 >> +102 >> +103 >> +update t5 set a=a+100; >> DROP TABLE t1; >> DROP TABLE t2; >> DROP TABLE t3; >> DROP TABLE t4; >> +DROP TABLE t5; >> >> diff --git a/mysql-test/suite/galera/t/galera_prepared_statement.test >> b/mysql-test/suite/galera/t/galera_prepared_statement.test >> index 3bee097..debc00e 100644 >> --- a/mysql-test/suite/galera/t/galera_prepared_statement.test >> +++ b/mysql-test/suite/galera/t/galera_prepared_statement.test >> @@ -38,8 +38,33 @@ ALTER TABLE t1 DROP COLUMN f1; >> --error ER_TRUNCATED_WRONG_VALUE_FOR_FIELD >> EXECUTE st1; >> >> +# MDEV-10812 >> +# On Closing Prepare Stamemnt, When wsrep_conflict_state is ABORTED >> +# It causes wrong response to be sent on Clients. >> + >> +# First Create a Deadlock >> --connection node_1 >> +SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; >> +CREATE TABLE t5(a int primary key); >> +INSERT INTO t5 VALUES(1),(2),(3); >> +START TRANSACTION ; >> +PREPARE st5 FROM 'SELECT * FROM t5'; >> +EXECUTE st5; >> +update t5 set a=a+100; >> +EXECUTE st5; >> + >> +--sleep 2 >> +--connection node_2 >> +update t5 set a=a+100; >> + >> +--sleep 2 >> +--connection node_1 >> +# here we have deadlock >> +--disconnect node_1 >> + >> +--connection node_2 >> DROP TABLE t1; >> DROP TABLE t2; >> DROP TABLE t3; >> DROP TABLE t4; >> +DROP TABLE t5; > > > > The test always hits command != COM_QUIT assert if I revert : > > + if (thd->wsrep_conflict_state == ABORTED && > + command != COM_STMT_CLOSE && command != COM_QUIT) > > So, I modified your test a bit (simplified) to not use PS. > > --echo # > --echo # MDEV-10812: On closing prepare stamemnt, 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; > > I think it should be ok. > > Yes, also Because Initial prepared statement test was written because, I thought we will hit COM_STMT_CLOSE, but is simple not possible using mtr. Test changed. >> >> diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc >> index 033e88a..d45b196 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 STMT_CLOSE execute even if wsrep aborted */ > Changed. > > 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,8 @@ bool dispatch_command(enum enum_server_command >> command, THD *thd, >> >> if (WSREP(thd)) >> { >> + DBUG_ASSERT((command != COM_QUIT && command != COM_STMT_CLOSE) >> + || thd->get_stmt_da()->is_disabled()); > > > Please add a comment explaining this assert. > Added. > Thanks, > 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 > > http://lists.askmonty.org/pipermail/commits/2017-January/010534.html -- Regards Sachin Setiya Software Engineer at MariaDB -- Regards Sachin Setiya Software Engineer at MariaDB

1 0

[Maria-developers] MDEV-10142 - / MDEV-10343 - bb-10.2-compatibility
by jerome brauge 27 Jan '17

27 Jan '17

Hi, I'm testing datatype compatibility provide by MDEV-10343 and I have some comments: 1) Oracle character datatype (char, varchar, varchar2) doesn't accept a length of 0 char Example : select cast('tt' as char(0)) from dual; ORA-01723: zero-length columns are not allowed MariaDB return an empty string (to relate with MDEV-10574) This point is a study case, no matter. 2) NUMBER Type You have choosing TYPE_DOUBLE if scale/prec is not specified and I think that it's a mistake for 2 reasons: - Oracle NUMBER() is near an "exact" datatype and cannot be replace by a standard double. - Convert number to char never use scientific notation The use of a decimal(64,24) makes it possible to obtain results very close to those of oracle. I attach two files to show this. In fact FLOAT and INTEGER are subtype of NUMBER for Oracle. MariaDB float and double seems to be like BINARY_FLOAT and BINARY_DOUBLE. See https://docs.oracle.com/cd/B28359_01/server.111/b28285/sqlqr06.htm#CHDBBHHE for more details. Best regard, Jérôme.

2 1

Re: [Maria-developers] [Commits] fb49b98: MDEV-10436 non-deterministic vcol does not force rbr
by Daniel Black 27 Jan '17

27 Jan '17

On 25/01/17 00:33, sachin wrote: > @@ -5824,6 +5826,16 @@ int THD::decide_logging_format(TABLE_LIST *tables) > table->table->file->ht) > multi_access_engine= TRUE; > > + /* > + Loop through each table field if it is virtual field check if it is deterministic > + or not. > + */ > + for (field_ptr= table->table->field; *field_ptr; field_ptr++) > + { > + field= *field_ptr; > + if (field->vcol_info && field->vcol_info->flags & VCOL_NOT_STRICTLY_DETERMINISTIC) > + lex->set_stmt_unsafe(LEX::BINLOG_STMT_UNSAFE_NON_DETER_VCOL); you could break the loop at this point. > + } > prev_access_table= table->table; > } >

1 0