- 08 Mar, 2012 7 commits
-
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
This bug has been there at least since MySQL 4.0.9. (Before 4.0.9, the code probably was even more severely broken.) btr_pcur_restore_position(): When cursor restoration fails, before invoking btr_pcur_store_position() move to the previous or next record unless cursor->rel_pos==BTR_PCUR_ON or the record was not a user record. This bug can cause skipped records when btr_pcur_store_position() is called on the last record of a page. A symptom would be record count mismatch in CHECK TABLE, or failure to find a record to delete-mark or update or purge. The following operations should be affected by the bug: * row_search_for_mysql(): SELECT, UPDATE, REPLACE, CHECK TABLE, (almost anything else than INSERT) * foreign key CASCADE operations * row_merge_read_clustered_index(): index creation (since MySQL 5.1 InnoDB Plugin) * multi-threaded purge (after MySQL 5.5): not sure, but it might fail to purge some records Not all callers of btr_pcur_restore_position() should be affected. Anything that asserts or checks that restoration succeeds is unaffected. For example, cursor restoration on the change buffer tree should always succeed, because access is being protected by additional latches. Likewise, rollback, or any code accesses data dictionary tables while holding dict_sys->mutex should be safe. rb:967 approved by Jimmy Yang
-
- 06 Mar, 2012 5 commits
-
-
Tor Didriksen authored
storage/innobase/include/sync0rw.ic: Prerequisite for compiling with gcc4 on solaris: ignore result from os_compare_and_swap_ulint storage/myisam/mi_dynrec.c: Prerequisite for compiling with gcc4 on solaris: cast to void*
-
Tor Didriksen authored
Post-push fixes. mysys/stacktrace.c: Missing comma after "%s" format specifier. sql/mysqld.cc: Move #define to signal_handler.cc sql/signal_handler.cc: Missing #define UNSAFE_DEFAULT_LINUX_THREADS 200
-
Marko Mäkelä authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
GEOMETRY FUNCTION ARGUMENTS Fixed --ps-protocol gis test failure.
-
- 05 Mar, 2012 3 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
A defect in the subquery substitution code may lead to a server crash: setting substitution's name should be followed by setting its length (to keep them in sync). mysql-test/r/gis.result: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS test result. mysql-test/t/gis.test: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS test case. sql/item_subselect.cc: BUG#12537203 - CRASH WHEN SUBSELECTING GLOBAL VARIABLES IN GEOMETRY FUNCTION ARGUMENTS set substitution's name length as well as the name itself (to keep them in sync).
-
Ramil Kalimullin authored
Problem: lack of incoming geometry data validation may lead to a server crash when ISCLOSED() function called. Solution: necessary incoming data check added. mysql-test/r/gis.result: Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS test result. mysql-test/t/gis.test: Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS test case. sql/spatial.cc: Fix for BUG#12414917 - ISCLOSED() CRASHES ON 64-BIT BUILDS check if a LINESTRING has at least one point as we rely on that further.
-
- 01 Mar, 2012 4 commits
-
-
Annamalai Gurusami authored
-
Annamalai Gurusami authored
Taking care of it.
-
Annamalai Gurusami authored
-
Annamalai Gurusami authored
There are two threads. In one thread, dml operation is going on involving cascaded update operation. In another thread, alter table add foreign key constraint is happening. Under these circumstances, it is possible for the dml thread to access a dict_foreign_t object that has been freed by the ddl thread. The debug sync test case provides the sequence of operations. Without fix, the test case will crash the server (because of newly added assert). With fix, the alter table stmt will return an error message. Backporting the fix from MySQL 5.5 to 5.1 rb:961 rb:947
-
- 29 Feb, 2012 4 commits
-
-
Mattias Jonsson authored
-
Mattias Jonsson authored
-
Praveenkumar Hulakund authored
Analysis: ======================== sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input, instead of escape character in a string literal then sql_mode can be set to "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary character like any other. SQL_MODE set applies to the current client session. And while creating the stored procedure, MySQL stores the current sql_mode and always executes the stored procedure in sql_mode stored with the Procedure, regardless of the server SQL mode in effect when the routine is invoked. In the scenario (for which bug is reported), the routine is created with sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode is "" (NOT SET) by executing statement "call testp('Axel\'s')". Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function) is considered as escape character and column "a" (of table "t1") values are updated with "Axel's". The binary log generated for above update operation is as below, set sql_mode=XXXXXX (for no_backslash_escapes) update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci'); While logging stored procedure statements, the local variables (params) used in statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const) On slave, these logs are applied. NAME_CONST is parsed to get the variable and its value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode is also logged in. So that at slave this sql_mode is set before executing the statements of routine. So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character and parsing reported error for "'" (as we have only one "'" no backslash). At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES". But above error reported while writing bin log, "'" (of Axel's) is escaped with "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped while writing NAME_CONST for string variable(param, local variable) in bin log irrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is that logging string parameter does not take into account sql_mode value. Fix: ======================== So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping characters as (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to escape such characters while writing NAME_CONST for string variables in bin log. And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is represented as ''. http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several ways to include quote characters within a string: )
-
Praveenkumar Hulakund authored
Analysis: ======================== sql_mode "NO_BACKSLASH_ESCAPES": When user want to use backslash as character input, instead of escape character in a string literal then sql_mode can be set to "NO_BACKSLASH_ESCAPES". With this mode enabled, backslash becomes an ordinary character like any other. SQL_MODE set applies to the current client session. And while creating the stored procedure, MySQL stores the current sql_mode and always executes the stored procedure in sql_mode stored with the Procedure, regardless of the server SQL mode in effect when the routine is invoked. In the scenario (for which bug is reported), the routine is created with sql_mode=NO_BACKSLASH_ESCAPES. And routine is executed with the invoker sql_mode is "" (NOT SET) by executing statement "call testp('Axel\'s')". Since invoker sql_mode is "" (NOT_SET), the '\' in 'Axel\'s'(argument to function) is considered as escape character and column "a" (of table "t1") values are updated with "Axel's". The binary log generated for above update operation is as below, set sql_mode=XXXXXX (for no_backslash_escapes) update test.t1 set a= NAME_CONST('var',_latin1'Axel\'s' COLLATE 'latin1_swedish_ci'); While logging stored procedure statements, the local variables (params) used in statements are replaced with the NAME_CONST(var_name, var_value) (Internal function) (http://dev.mysql.com/doc/refman/5.6/en/miscellaneous-functions.html#function_name-const) On slave, these logs are applied. NAME_CONST is parsed to get the variable and its value. Since, stored procedure is created with sql_mode="NO_BACKSLASH_ESCAPES", the sql_mode is also logged in. So that at slave this sql_mode is set before executing the statements of routine. So at slave, sql_mode is set to "NO_BACKSLASH_ESCAPES" and then while parsing NAME_CONST of string variable, '\' is considered as NON ESCAPE character and parsing reported error for "'" (as we have only one "'" no backslash). At slave, parsing was proper with sql_mode "NO_BACKSLASH_ESCAPES". But above error reported while writing bin log, "'" (of Axel's) is escaped with "\" character. Actually, all special characters (n, r, ', ", \, 0...) are escaped while writing NAME_CONST for string variable(param, local variable) in bin log Airrespective of "NO_BACKSLASH_ESCAPES" sql_mode. So, basically, the problem is that logging string parameter does not take into account sql_mode value. Fix: ======================== So when sql_mode is set to "NO_BACKSLASH_ESCAPES", escaping characters as (n, r, ', ", \, 0...) should be avoided. To do so, added a check to not to escape such characters while writing NAME_CONST for string variables in bin log. And when sql_mode is set to NO_BACKSLASH_ESCAPES, quote character "'" is represented as ''. http://dev.mysql.com/doc/refman/5.6/en/string-literals.html (There are several ways to include quote characters within a string: ) mysql-test/r/sql_mode.result: Added test case for Bug#12601974. mysql-test/suite/binlog/r/binlog_sql_mode.result: Appended result of test cases added for Bug#12601974. mysql-test/suite/binlog/t/binlog_sql_mode.test: Added test case for Bug#12601974. mysql-test/t/sql_mode.test: Appended result of test cases added for Bug#12601974.
-
- 28 Feb, 2012 4 commits
-
-
Marko Mäkelä authored
row_drop_table_for_mysql(): Really flag the indexes unavailable before starting to drop the table.
-
Manish Kumar authored
This is a post commit patch for failing test on windows.
-
Marko Mäkelä authored
also filed as Bug#13146269, Bug#13713178 btr_get_size(): Add mtr_t parameter. Require that the caller S-latches index->lock. If index->page==FIL_NULL or the index is to be dropped, return ULINT_UNDEFINED to indicate that the statistics are unavailable. dict_update_statistics(): If btr_get_size() returns ULINT_UNDEFINED, fake the index cardinality statistics. dict_index_set_page(): Unused function, remove. row_drop_table_for_mysql(): Before starting to drop the table, mark the indexes unavailable in the data dictionary cache while holding index->lock X-latch. ha_innobase::prepare_drop_index(), ha_innobase::final_drop_index(): When setting index->to_be_dropped, acquire the index->lock X-latch. rb:960 approved by Jimmy Yang
-
Manish Kumar authored
This is a post commit patch for failing test on windows.
-
- 29 Feb, 2012 1 commit
-
-
Praveenkumar Hulakund authored
-
- 28 Feb, 2012 3 commits
-
-
Manish Kumar authored
Problem - The default port number shown in SHOW SLAVE HOSTS is always 3306 though the slave is actually listening on a different port number. This is a problem as the user can not be sure whether this port value can be trusted and so client trying to read replication topology can get confused. Fix - 3306 ceases to be the default value of report-port. Moreover report-port does not have a static default any longer. Instead we initialize report-port to 0 as the new default value and change it based on two checks : 1) If report_port is not set, the slave reports the port number its listening on. (i.e. if report-port is not set we get the actual value of the slave's port number). 2) If report-port is set, we show the value report-port is set to, as the slave's port number. mysql-test/include/show_slave_hosts.inc: A .inc file is added to use show slave hosts in the new test added. mysql-test/r/mysqld--help-notwin.result: Updated the result file to show the default value passed for report-port. mysql-test/suite/rpl/r/rpl_report_port.result: The result file for the new test that is added. mysql-test/suite/rpl/r/rpl_show_slave_hosts.result: Updated the result file to show the default value passed for report-port. mysql-test/suite/rpl/t/rpl_report_port-slave.opt: Option file for the new test added. mysql-test/suite/rpl/t/rpl_report_port.test: Added a test to check the correct functionality of report-port. We check this by running the replication twice. In the first run we do not set the value of report-port through the opt file and get the actual port number of the slave's port. We then restart the server with report-port set to some value (in this case 9000) and check the value reported for the slave's port number. mysql-test/suite/sys_vars/t/report_port_basic.test: Update the test file to show the value for report-port. It is replaced with SLAVE_PORT as the actual value of the report-port will change with each run. sql/mysqld.cc: Changed the value reported by report port : 1. If the value for report-port is not set we assign report-port to be the actual port number of the slave (mysqld_port). 2. If report-port is set we get the value set for the report-port. sql/sys_vars.cc: Passed 0 as the default value of the report-port.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 27 Feb, 2012 3 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Annamalai Gurusami authored
There are two threads. In one thread, dml operation is going on involving cascaded update operation. In another thread, alter table add foreign key constraint is happening. Under these circumstances, it is possible for the dml thread to access a dict_foreign_t object that has been freed by the ddl thread. The debug sync test case provides the sequence of operations. Without fix, the test case will crash the server (because of newly added assert). With fix, the alter table stmt will return an error message. rb:947 approved by Jimmy Yang
-
- 24 Feb, 2012 5 commits
-
-
Luis Soares authored
Automerged approved cset.
-
Luis Soares authored
PROBLEM: After WL 4144, when using MyISAM Merge tables, the routine open_and_lock_tables will append to the list of tables to lock, the base tables that make up the MERGE table. This has two side-effects in replication: 1. On the master side, we log additional table maps for the base tables, since they appear in the list of locked tables, even though we don't really use them at the slave. 2. On the slave side, when opening a MERGE table while applying a ROW event, additional tables are appended to the list of tables to lock. Side-effect #1 is not harmful. It's just that when using MyISAM Merge tables a few table maps more may be logged. Side-effect #2, is harmful, because the list rli->tables_to_lock is an extended structure from TABLE_LIST in which the extra fields are filled from the table maps that are processed. Since open_and_lock_tables appends tables to the list after all table map events have been processed we end up with entries without replication/table map data on them. Thus when trying to access that info for these extra tables, the server will crash. SOLUTION: We fix side-effect #2 by making sure that we access the replication part of the structure for those in the list that were accounted for when processing the correspondent table map events. All in all, we never go beyond rli->tables_to_lock_count. We also deploy an assertion when clearing rli->tables_to_lock, making sure that the base tables are not in the list anymore (were closed in close_thread_tables).
-
Jimmy Yang authored
-
Chaithra Gopalareddy authored
-
Chaithra Gopalareddy authored
CHECK_SIMPLE_EQUALITY PROBLEM: Crash in "check_simple_equality" when using a subquery with "IN" and "ALL" in prepare. ANALYSIS: Crash can be reproduced using a simplified query like this one: prepare s from "select 1 from g1 where 1 < all ( select @:=(1 in (select 1 from g1)) from g1)"; This bug is currently present only on 5.5.and 5.1. Its fixed as part of work log(#1110) in 5.6. We are taking one change to fix this in 5.5 and 5.1. Problem seems to be present because we are trying to evaluate "is_null" on an argument which is part of a subquery (In Item_is_not_null_test::update_used_tables()). But the condition to evaluate is only when we do not have a sub query present, which means to say that "with_subselect" is not set. With respect to the above query, we create an object of type "Item_in_optimizer" which by definition is always associated with a subquery. While in 5.6 we set "with_subselect" to true for "Item_in_optimizer" object, we do not do the same in 5.5. This results in the evaluation for "is_null" resulting in a coredump. So, we are now setting "with_subselect" to true for "Item_in_optimizer" in 5.1 and 5.5. mysql-test/r/func_in.result: Result file changes for the test case added mysql-test/t/func_in.test: Test case added for Bug#13012483 sql/item_cmpfunc.h: Changed Item_in_optimizer::Item_in_optimizer( ) to set "with_subselect" to true
-
- 22 Feb, 2012 1 commit
-
-
Tatjana Azundris Nuernberg authored
-