- 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
-
- 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 2 commits
-
-
Marko Mäkelä authored
row_drop_table_for_mysql(): Really flag the indexes unavailable before starting to drop the table.
-
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
-
- 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 3 commits
-
-
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.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 20 Feb, 2012 1 commit
-
-
Mattias Jonsson authored
RESULT FROM PREVIOUS TRANSACTION The current Query Cache API is not fully compatible with the partitioning engine. There is no good way to implement support for QC due to: 1) a static callback for ha_partition would need to have access to all partition names and call the underlying callback for each [sub]partition with the correct name. 2) pruning would be impossible, even if one used the ulonglong engine_data due to if engine_data is changed, the table is invalidated by the QC. So the only viable solution to avoid incorrect data is to not allow caching of queries using partitioned tables. (There are some extra changes, due to removal of \r as line break)
-
- 19 Feb, 2012 1 commit
-
-
Tatjana Azundris Nuernberg authored
If a query's end time is before before its start time, the system clock has been turn back (daylight savings time etc.). When the system clock is changed, we can't tell for certain a given query was actually slow. We did not protect against logging such a query with a bogus execution time (resulting from end_time - start_time being negative), and possibly logging it even though it did not really take long to run. We now have a sanity check in place. sql/sql_parse.cc: Make sure end time is not before start time - otherwise, we can be SURE the system clock was changed in between, but not by how much. In other words, when the clock is changed, we don't know how long a query ran, and whether it was slow.
-
- 17 Feb, 2012 1 commit
-
-
Marko Mäkelä authored
This bug was originally filed and fixed as Bug#12612184. The original fix was buggy, and it was patched by Bug#12704861. Also that patch was buggy (potentially breaking crash recovery), and both fixes were reverted. This fix was not ported to the built-in InnoDB of MySQL 5.1, because the function signatures of many core functions are different from InnoDB Plugin and later versions. The block allocation routines and their callers would have to changed so that they handle block descriptors instead of page frames. When a record is updated so that its size grows, non-updated columns can be selected for external (off-page) storage. The bug is that the initially inserted updated record contains an all-zero BLOB pointer to the field that was not updated. Only after the BLOB pages have been allocated and written, the valid pointer can be written to the record. Between the release of the page latch in mtr_commit(mtr) after btr_cur_pessimistic_update() and the re-latching of the page in btr_pcur_restore_position(), other threads can see the invalid BLOB pointer consisting of 20 zero bytes. Moreover, if the system crashes at this point, the situation could persist after crash recovery, and the contents of the non-updated column would be permanently lost. The problem is amplified by the ROW_FORMAT=DYNAMIC and ROW_FORMAT=COMPRESSED that were introduced in innodb_file_format=barracuda in InnoDB Plugin, but the bug does exist in all InnoDB versions. The fix is as follows. After a pessimistic B-tree operation that needs to write out off-page columns, allocate the pages for these columns in the mini-transaction that performed the B-tree operation (btr_mtr), but write the pages in a separate mini-transaction (blob_mtr). Do mtr_commit(blob_mtr) before mtr_commit(btr_mtr). A quirk: Do not reuse pages that were previously freed in btr_mtr. Only write the off-page columns to 'fresh' pages. In this way, crash recovery will see redo log entries for blob_mtr before any redo log entry for btr_mtr. It will apply the BLOB page writes to pages that were marked free at that point. If crash recovery fails to see all of the btr_mtr redo log, there will be some unreachable BLOB data in free pages, but the B-tree will be in a consistent state. btr_page_alloc_low(): Renamed from btr_page_alloc(). Add the parameter init_mtr. Return an allocated block, or NULL. If init_mtr!=mtr but the page was already X-latched in mtr, do not initialize the page. btr_page_alloc(): Wrapper for btr_page_alloc_for_ibuf() and btr_page_alloc_low(). btr_page_free(): Add a debug assertion that the page was a B-tree page. btr_lift_page_up(): Return the father block. btr_compress(), btr_cur_compress_if_useful(): Add the parameter ibool adjust, for adjusting the cursor position. btr_cur_pessimistic_update(): Preserve the cursor position when big_rec will be written and the new flag BTR_KEEP_POS_FLAG is defined. Remove a duplicate rec_get_offsets() call. Keep the X-latch on index->lock when big_rec is needed. btr_store_big_rec_extern_fields(): Replace update_inplace with an operation code, and local_mtr with btr_mtr. When not doing a fresh insert and btr_mtr has freed pages, put aside any pages that were previously X-latched in btr_mtr, and free the pages after writing out all data. The data must be written to 'fresh' pages, because btr_mtr will be committed and written to the redo log after the BLOB writes have been written to the redo log. btr_blob_op_is_update(): Check if an operation passed to btr_store_big_rec_extern_fields() is an update or insert-by-update. fseg_alloc_free_page_low(), fsp_alloc_free_page(), fseg_alloc_free_extent(), fseg_alloc_free_page_general(): Add the parameter init_mtr. Return an allocated block, or NULL. If init_mtr!=mtr but the page was already X-latched in mtr, do not initialize the page. xdes_get_descriptor_with_space_hdr(): Assert that the file space header is being X-latched. fsp_alloc_from_free_frag(): Refactored from fsp_alloc_free_page(). fsp_page_create(): New function, for allocating, X-latching and potentially initializing a page. If init_mtr!=mtr but the page was already X-latched in mtr, do not initialize the page. fsp_free_page(): Add ut_ad(0) to the error outcomes. fsp_free_page(), fseg_free_page_low(): Increment mtr->n_freed_pages. fsp_alloc_seg_inode_page(), fseg_create_general(): Assert that the page was not previously X-latched in the mini-transaction. A file segment or inode page should never be allocated in the middle of an mini-transaction that frees pages, such as btr_cur_pessimistic_delete(). fseg_alloc_free_page_low(): If the hinted page was allocated, skip the check if the tablespace should be extended. Return NULL instead of FIL_NULL on failure. Remove the flag frag_page_allocated. Instead, return directly, because the page would already have been initialized. fseg_find_free_frag_page_slot() would return ULINT_UNDEFINED on error, not FIL_NULL. Correct a bogus assertion. fseg_alloc_free_page(): Redefine as a wrapper macro around fseg_alloc_free_page_general(). buf_block_buf_fix_inc(): Move the definition from the buf0buf.ic to buf0buf.h, so that it can be called from other modules. mtr_t: Add n_freed_pages (number of pages that have been freed). page_rec_get_nth_const(), page_rec_get_nth(): The inverse function of page_rec_get_n_recs_before(), get the nth record of the record list. This is faster than iterating the linked list. Refactored from page_get_middle_rec(). trx_undo_rec_copy(): Add a debug assertion for the length. trx_undo_add_page(): Return a block descriptor or NULL instead of a page number or FIL_NULL. trx_undo_report_row_operation(): Add debug assertions. trx_sys_create_doublewrite_buf(): Assert that each page was not previously X-latched. page_cur_insert_rec_zip_reorg(): Make use of page_rec_get_nth(). row_ins_clust_index_entry_by_modify(): Pass BTR_KEEP_POS_FLAG, so that the repositioning of the cursor can be avoided. row_ins_index_entry_low(): Add DEBUG_SYNC points before and after writing off-page columns. If inserting by updating a delete-marked record, do not reposition the cursor or commit the mini-transaction before writing the off-page columns. row_build(): Tighten a debug assertion about null BLOB pointers. row_upd_clust_rec(): Add DEBUG_SYNC points before and after writing off-page columns. Do not reposition the cursor or commit the mini-transaction before writing the off-page columns. rb:939 approved by Jimmy Yang
-
- 16 Feb, 2012 6 commits
-
-
Marko Mäkelä authored
error LNK2001: unresolved external symbol _debug_sync_C_callback_ptr
-
Kent Boortz authored
-
MySQL Build Team authored
-
Marko Mäkelä authored
OF WIDE RECORDS row_ins_index_entry_low(), row_upd_clust_rec(): Make a redo log checkpoint if a DEBUG flag is set. Add DEBUG_SYNC around btr_store_big_rec_extern_fields(). rb:946 approved by Jimmy Yang
-
Marko Mäkelä authored
-
Kent Boortz authored
-
- 15 Feb, 2012 4 commits
-
-
Kent Boortz authored
-
MySQL Build Team authored
-
Marko Mäkelä authored
Before killing the server, tell mysql-test-run that it is to be expected. Discussed with Bjorn Munch on IM.
-
Marko Mäkelä authored
-
- 10 Feb, 2012 1 commit
-
-
Sunny Bains authored
During FIC error handling the trx->error_state was not being set to DB_SUCCESS after failure, before attempting the next DDL SQL operation. This reset to DB_SUCCESS is somewhat of a requirement though not explicitly stated anywhere. The fix is to reset it to DB_SUCCESS in row0merge.cc if row_merge_rename_indexes or row_merge_drop_index functions fail, also reset to DB_SUCCESS at trx commit. rb://935 Approved by Jimmy Yang.
-
- 06 Feb, 2012 1 commit
-
-
Vasil Dimov authored
GRACEFUL SHUTDOWN During startup mysql picks up .frm files from the tmpdir directory and tries to drop those tables in the storage engine. The problem is that when tmpdir ends in / then ha_innobase::delete_table() is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it to "/#sql123" and calls row_drop_table_for_mysql() which of course fails to delete the table entry from the InnoDB dictionary cache. ha_innobase::delete_table() returns an error but nevertheless mysql wipes away the .frm file and the entry in the InnoDB dictionary cache remains orphaned with no easy way to remove it. The "no easy" way to remove it is to create a similar temporary table again, copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file after restart and will try to issue drop table for "/var/tmp/#sql123" (notice do double slash), ha_innobase::delete_table() will normalize it to "tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the table entry from the dictionary cache. The solution is to fix normalize_table_name_low() to normalize things like "/var/tmp//table" correctly to "tmp/table". This patch also adds a test function which invokes normalize_table_name_low() with various inputs to make sure it works correctly and a mtr test that calls this test function. Reviewed by: Marko (http://bur03.no.oracle.com/rb/r/929/)
-
- 03 Feb, 2012 1 commit
-
-
Ashish Agarwal authored
CORRUPTED WHEN RUN CONCURRENTLY WITH ISSUE: Table corruption due to concurrent queries. Different threads running check, repair query along with insert. Locks not properly acquired in repair query. Rows are inserted inbetween repair query. SOLUTION: Mutex lock is acquired before the repair call. Concurrent queries wont effect the call to repair.
-
- 02 Feb, 2012 1 commit
-
-
Alexander Barkov authored
Recording correct test results. modified: mysql-test/suite/engines/funcs/r/db_alter_collate_ascii.result mysql-test/suite/engines/funcs/r/db_alter_collate_utf8.result
-