- 18 Apr, 2012 3 commits
-
-
Tor Didriksen authored
Stored program cache produces wrong result in same THD.
-
Nuno Carvalho authored
Currently SHOW MASTER LOGS and SHOW BINARY LOGS require the SUPER privilege. Monitoring tools (such as MEM) often want to check this output - for instance MEM generates the SUM of the sizes of the logs reported here, and puts that in the Replication overview within the MEM Dashboard. However, because of the SUPER requirement, these tools often have an account that holds open the connection whilst monitoring, and can lock out administrators when the server gets overloaded and reaches max_connections - there is already another SUPER privileged account connected, the "monitor". As SHOW MASTER STATUS, and all other replication related statements, return with either REPLICATION CLIENT or SUPER privileges, this worklog is to make SHOW MASTER LOGS and SHOW BINARY LOGS be consistent with this as well, and allow both of these commands with either SUPER or REPLICATION CLIENT. This allows monitoring tools to not require a SUPER privilege any more, so is safer in overloaded situations, as well as being more secure, as lighter privileges can be given to users of such tools or scripts.
-
Chaithra Gopalareddy authored
ORDER BY COUNT(*) LIMIT. PROBLEM: With respect to problem in the bug description, we exhibit different behaviors for the two tables presented, because innodb statistics (rec_per_key in this case) are updated for the first table and not so for the second one. As a result the query plan gets changed in test_if_skip_sort_order to use 'index' scan. Hence the difference in the explain output. (NOTE: We can reproduce the problem with first table by reducing the number of tuples and changing the table structure) The varied output w.r.t the query on the second table is because of the result in the query plan change. When a query plan is changed to use 'index' scan, after the call to test_if_skip_sort_order, we set keyread to TRUE immedietly. If for some reason we drop this index scan for a filesort later on, we fetch only the keys not the entire tuple. As a result we would see junk values in the result set. Following is the code flow: Call test_if_skip_sort_order -Choose an index to give sorted output -If this is a covering index, set_keyread to TRUE -Set the scan to INDEX scan Call test_if_skip_sort_order second time -Index is not chosen (note that we do not pass the actual limit value second time. Hence we do not choose index scan second time which in itself is a bug fixed in 5.6 with WL#5558) -goto filesort Call filesort -Create quick range on a different index -Since keyread is set to TRUE, we fetch only the columns of the index -results in the required columns are not fetched FIX: Remove the call to set_keyread(TRUE) from test_if_skip_sort_order. The access function which is 'join_read_first' or 'join_read_last' calls set_keyread anyways. mysql-test/r/func_group_innodb.result: Added test result for Bug#12713907 mysql-test/t/func_group_innodb.test: Added test case for Bug#12713907 sql/sql_select.cc: Remove the call to set_keyread as we do it from access functions 'join_read_first' and 'join_read_last'
-
- 17 Apr, 2012 1 commit
-
-
Georgi Kodinov authored
-
- 09 Apr, 2012 1 commit
-
-
Venkata Sidagam authored
This bug is a duplicate of Bug #31173, which was pushed to the mysql-trunk 5.6 on 4th Aug, 2010. This is just a back-port of the fix mysql-test/r/mysqlslap.result: A test added as part of the fix for Bug #59107 mysql-test/t/mysqlslap.test: A test added as part of the fix for Bug #59107
-
- 06 Apr, 2012 1 commit
-
-
Mayank Prasad authored
Background : In mysql-5.1, in a fix for bug#47485, code has been changed for mysql client (libmysql/libmysql.c) but corresponding code was not changed for embedded mysql. In that code change, after execution of a statement, mysql_stmt_store_result() checks for mysql->state to be MYSQL_STATUS_STATEMENT_GET_RESULT, instead of MYSQL_STATUS_GET_RESULT (earlier). Reason: In embedded mysql code, after execution, mysql->state was not set to MYSQL_STATUS_STATEMENT_GET_RESULT, so it was throwing OUT_OF_SYNC error. Fix: Fixed the code in libmysqld/lib_sql.cc to have mysql->state to be set to MYSQL_STATUS_STATEMENT_GET_RESULT after execution.
-
- 28 Mar, 2012 3 commits
-
-
Praveenkumar Hulakund authored
Analysis: ------------------------------- According to the Manual (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html): "Column, index, stored routine, and event names are not case sensitive on any platform, nor are column aliases." In other words, 'lower_case_table_names' does not affect the behaviour of those identifiers. On the other hand, trigger names are case sensitive on some platforms, and case insensitive on others. 'lower_case_table_names' does not affect the behaviour of trigger names either. The bug was that SHOW statements did case sensitive comparison for stored procedure / stored function / event names. Fix: Modified the code so that comparison in case insensitive for routines and events for "SHOW" operation. As part of this commit, only fixing the test failures due to the actual code fix.
-
Sunny Bains authored
-
Sunny Bains authored
Change the type of purge_sys_t::n_pages_handled and purge_sys_t::handle_limit to ulonglong from ulint. On a 32 bit system doing ~700 deletes per second the counters can overflow in ~3.5 months, if they are 32 bit. Approved by Jimmy Yang over IM.
-
- 27 Mar, 2012 2 commits
-
-
Tor Didriksen authored
-
Praveenkumar Hulakund authored
Analysis: ------------------------------- According to the Manual (http://dev.mysql.com/doc/refman/5.1/en/identifier-case-sensitivity.html): "Column, index, stored routine, and event names are not case sensitive on any platform, nor are column aliases." In other words, 'lower_case_table_names' does not affect the behaviour of those identifiers. On the other hand, trigger names are case sensitive on some platforms, and case insensitive on others. 'lower_case_table_names' does not affect the behaviour of trigger names either. The bug was that SHOW statements did case sensitive comparison for stored procedure / stored function / event names. Fix: Modified the code so that comparison in case insensitive for routines and events for "SHOW" operation.
-
- 21 Mar, 2012 1 commit
-
-
Joerg Bruehe authored
solve a conflict in ".bzr-mysql/default.conf".
-
- 20 Mar, 2012 2 commits
- 16 Mar, 2012 1 commit
-
-
Annamalai Gurusami authored
The test case must insert all the records using a single transaction. Otherwise the test case takes more than 15 minutes and will time out in pb2 and mtr.
-
- 15 Mar, 2012 3 commits
-
-
Inaam Rana authored
FROM BUFFER POOL rb://975 approved by: Marko Makela There is a race in lock_validate() where we try to access a page without ensuring that the tablespace stays valid during the operation i.e.: it is not deleted. This patch tries to fix that by using an existing flag (the flag is renamed to make it's name more generic in line with it's new use).
-
Inaam Rana authored
rb://976 approved by: Marko Makela Add an assertion to ensure that string overflow is not happening. Pointed by Coverity analysis.
-
Inaam Rana authored
IN OS_THREAD_EQ rb://977 approved by: Marko Makela rw_lock::writer_thread field contains the thread id of current x-holder or wait-x thread. This field is un-initialized at lock creation and is written to for the first time when an attempt is made to x-lock. Current code considers ::writer_thread as valid memory region only when the lock is held in x-mode (or there is an x-waiter). This is an overkill and it generates valgrind warnings. The fix is to consider ::writer_thread as valid memory region once it has been written to. Reasoning: ========== The ::writer_thread can be safely considered valid because: * We only ever do comparison with current calling threads id. * We only ever do comparison when ::recursive flag is set * We always unset ::recursive flag in x-unlock * Same thread cannot be unlocking and attempting to lock at the same time * thread_id recycling is not an issue because before an id is recycled the thread must leave innodb meaning it must release all locks meaning it must unset ::recursive flag.
-
- 12 Mar, 2012 5 commits
-
-
Luis Soares authored
Adding missing sync_slave_with_master to the test case.
-
Luis Soares authored
-
Luis Soares authored
Hardening the test case: - including a diff_tables at the end. - increasing the tolerance on the relay limit size.
-
Luis Soares authored
Automerge with mysql-5.1.
-
Luis Soares authored
BUG#64503: mysql frequently ignores --relay-log-space-limit When the SQL thread goes to sleep, waiting for more events, it sets the flag ignore_log_space_limit to true. This gives the IO thread a chance to queue some more events and ultimately the SQL thread will be able to purge the log once it is rotated. By then the SQL thread resets the ignore_log_space_limit to false. However, between the time the SQL thread has set the ignore flag and the time it resets it, the IO thread will be queuing events in the relay log, possibly going way over the limit. This patch makes the IO and SQL thread to synchronize when they reach the space limit and only ask for one event at a time. Thus the SQL thread sets ignore_log_space_limit flag and the IO thread resets it to false everytime it processes one more event. In addition, everytime the SQL thread processes the next event, and the limit has been reached, it checks if the IO thread should rotate. If it should, it instructs the IO thread to rotate, giving the SQL thread a chance to purge the logs (freeing space). Finally, this patch removes the resetting of the ignore_log_space_limit flag from purge_first_log, because this is now reset by the IO thread every time it processes the next event when the limit has been reached. If the SQL thread is in a transaction, it cannot purge so, there is no point in asking the IO thread to rotate. The only thing it can do is to ask for more events until the transaction is over (then it can ask the IO to rotate and purge the log right away). Otherwise, there would be a deadlock (SQL would not be able to purge and IO thread would not be able to queue events so that the SQL would finish the transaction).
-
- 09 Mar, 2012 1 commit
-
-
Annamalai Gurusami authored
truncating, inserting the same set of rows. When a table is re-created with the same set of rows, the data file size must not grow. rb:968 Approved by Marko.
-
- 08 Mar, 2012 2 commits
-
-
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 1 commit
-
-
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
-
- 02 Mar, 2012 2 commits
-
-
Joerg Bruehe authored
-
Joerg Bruehe authored
to pick up some new security fixes that are in it. Patch provided by Georgi Kodinov.
-
- 29 Feb, 2012 3 commits
-
-
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 5 commits
-
-
Marko Mäkelä authored
row_drop_table_for_mysql(): Really flag the indexes unavailable before starting to drop the table.
-
Karen Langford authored
-
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
-
Joerg Bruehe authored
-
Joerg Bruehe authored
Update the year in the copyright notice, file "README".
-
- 27 Feb, 2012 1 commit
-
-
Marko Mäkelä authored
-
- 24 Feb, 2012 1 commit
-
-
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
-
- 21 Feb, 2012 1 commit
-
-
Vasil Dimov authored
Suppress innodb_bug34300 from failing if InnoDB prints: 120221 11:05:03 InnoDB: ERROR: the age of the last checkpoint is 9439048, InnoDB: which exceeds the log group capacity 9433498. by default the log capacity is 2 log files, 5 MB each.
-