- developers - lists.mariadb.org

[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

[Maria-developers] MDEV-11829 - Questions on timezones
by Seth Shelnutt 26 Jan '17

26 Jan '17

I am working on a patch for adding datetime parsing support for RFC3339 as reported in MDEV-11829. In examining methods to use the provided offset to convert the parsed datetime to the timezone of mariadb. I have some questions on the my_system_gmt_sec function in sql-common/my_time.c . >From testing on linux (rhel 7 and gentoo), it seems the timezone computed by my_system_gmt_sec is off by 7200 seconds and has a inverse sign. I am trying to determine why this is and if it is designed to be this way. From the comments in the file, it seems my_system_gmt_sec was designed specifically due to cross-platform issues. However there is no mention that it the timezone computed is suppose to be off or have an inverse sign. I could not find any usages of the my_time_zone global variable or where another function used the timezone computed by my_system_gmt_sec, so this might not effect anything, but I wanted some clarification. Here is some testing results: | ---------------------------- | ------------------------------------------ | -------------- | | Server TimeZone | my_system_gmt_sec timezone | Difference | | ---------------------------- | ------------------------------------------ | -------------- | | -18000 (-05:00 EST) | 25200 | 43200 | | 3600 (+01:00 CET) | -10800 | 14400 | | 0 (+00:00 GMT) | 7200 | 7200 | | ---------------------------- | ------------------------------------------ | -------------- | In testing I've been able to determine that the 7200 second deviation is caused by compensating for the "-3600" seconds twice, first in setting an initial timezone in my_init_time: https://github.com/MariaDB/server/blob/10.1/sql-common/my_time.c#L709 Inside my_system_gmt_sec the "current_timezone" is set to the "my_time_zone" which is at 3600 initially. Then below another 3600 is added to the timezone computation: https://github.com/MariaDB/server/blob/10.1/sql-common/my_time.c#L946 The diff variable that is computed has the correct offset, with an inverse sign. If current_timezone were set to "diff" then it would have the correct timezone but again with an inverse sign. The inverse sign comes from the doing t - l_time instead of l_time - t. Should the timezone computed have an inverse sign? Is there a reason it is offset by 7200 seconds? Perhaps the behavior is different on other platform, that I have not tested. Thank you, Seth Shelnutt

1 0

[Maria-developers] MDEV-11913 Split sp_get_item_value() into methods in Type_handler
by Alexander Barkov 26 Jan '17

26 Jan '17

Hello Sanja, Can you please review a patch for MDEV-11913? Thanks!

1 0

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

25 Jan '17

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. > > 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. > 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 */ > 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. 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

1 0

[Maria-developers] MDEV-11780 Crash with PREPARE + SP out parameter + literal
by Alexander Barkov 24 Jan '17

24 Jan '17

Hello Sergei, Please review a patch for MDEV-11780. Thanks!

2 3

[Maria-developers] Fwd: Mdev-10436 - Non-deterministic vcol does not force rbr
by Sachin Setiya 24 Jan '17

24 Jan '17

Hi Igor, Need a little help in Mdev-10436, I an sanja discussed that we need some method is Item class to see whether it can be determined deterministicly , Is it okay ? Can I change Item class to incorporate this change ? -- Regards Sachin Setiya Software Engineer at MariaDB -- Regards Sachin Setiya Software Engineer at MariaDB

2 1