- 09 Jul, 2010 1 commit
-
-
Marc Alff authored
This change is for performance optimization. Fixed the performance schema instrumentation interface as follows: - simplified mysql_unlock_mutex() - simplified mysql_unlock_rwlock() - simplified mysql_cond_signal() - simplified mysql_cond_broadcast() Changed the get_thread_XXX_locker apis to have one extra parameter, to provide memory to the instrumentation implementation. This API change allows to use memory provided by the caller, to avoid having to use thread local storage. Using this extra parameter will be done in a separate fix, this change is for the interface only. Adjusted all the code and unit tests accordingly.
-
- 08 Jul, 2010 9 commits
-
-
Davi Arnaut authored
Essentially, the problem is that safemalloc is excruciatingly slow as it checks all allocated blocks for overrun at each memory management primitive, yielding a almost exponential slowdown for the memory management functions (malloc, realloc, free). The overrun check basically consists of verifying some bytes of a block for certain magic keys, which catches some simple forms of overrun. Another minor problem is violation of aliasing rules and that its own internal list of blocks is prone to corruption. Another issue with safemalloc is rather the maintenance cost as the tool has a significant impact on the server code. Given the magnitude of memory debuggers available nowadays, especially those that are provided with the platform malloc implementation, maintenance of a in-house and largely obsolete memory debugger becomes a burden that is not worth the effort due to its slowness and lack of support for detecting more common forms of heap corruption. Since there are third-party tools that can provide the same functionality at a lower or comparable performance cost, the solution is to simply remove safemalloc. Third-party tools can provide the same functionality at a lower or comparable performance cost. The removal of safemalloc also allows a simplification of the malloc wrappers, removing quite a bit of kludge: redefinition of my_malloc, my_free and the removal of the unused second argument of my_free. Since free() always check whether the supplied pointer is null, redudant checks are also removed. Also, this patch adds unit testing for my_malloc and moves my_realloc implementation into the same file as the other memory allocation primitives. client/mysqldump.c: Pass my_free directly as its signature is compatible with the callback type -- which wasn't the case for free_table_ent.
-
Luis Soares authored
-
Marc Alff authored
-
Olav Sandstaa authored
from mysql-next-mr-opt-backporting. Bug#54515: Crash in opt_range.cc::get_best_group_min_max on SELECT from VIEW with GROUP BY When handling the grouping items in get_best_group_min_max, the items need to be of type Item_field. In this bug, an ASSERT triggered because the item used for grouping was an Item_direct_view_ref (i.e., the group column is from a view). The fix is to get the real_item since Item_ref* pointing to Item_field is ok. mysql-test/r/select.result: Add test for BUG#54515 mysql-test/t/select.test: Add test for BUG#54515 sql/opt_range.cc: Get the real_item() when processing grouping items in get_best_group_min_max.
-
Guilhem Bichot authored
from next-mr-bugfixing: BUG#54682 "set sql_select_limit=0 does not work"; let SQL_SELECT_LIMIT=0 work like it does in 5.1. mysql-test/suite/sys_vars/r/sql_select_limit_func.result: before the fix, the SET would emit a warning (0 being rounded up to 1) and SELECTs would return one row. sql/sys_vars.cc: 0 is allowed, it means an implicit LIMIT 0 (i.e. no rows returned)
-
Luis Soares authored
-
Luis Soares authored
-
Luis Soares authored
-
Luis Soares authored
-
- 07 Jul, 2010 3 commits
-
-
Luis Soares authored
-
Alexander Barkov authored
Problem: sha2() reported its result as BINARY Fix: - Inheriting Item_func_sha2 from Item_str_ascii_func - Setting max_length via fix_length_and_charset() instead of direct assignment. - Adding tests
-
Alexander Barkov authored
Problem: Item_copy did not set "fixed", which resulted in DBUG_ASSERT in some cases. Fix: adding initialization of the "fixed" member Adding tests: mysql-test/include/ctype_numconv.inc mysql-test/r/ctype_binary.result mysql-test/r/ctype_cp1251.result mysql-test/r/ctype_latin1.result mysql-test/r/ctype_ucs.result Adding initialization of the "fixed" member: sql/item.h
-
- 06 Jul, 2010 3 commits
-
-
Luis Soares authored
The server was not cleaning up dbug allocated memory before exiting. This is not a real problem, as this memory would be deallocated anyway. Nonetheless, we improve the mysqlbinlog exit procedure, wrt to memory book-keeping, when no parameter is given. To fix this, we deploy a call to my_thread_end() before the thread exits, which will also free pending dbug related allocated blocks.
-
Davi Arnaut authored
value and NO_ZERO_DATE The problem was that a older version of the error path for a failed admin statement relied upon a few error conditions being met in order to access a table handler, the first one being that the table object pointer was not NULL. Probably due to chance, in all cases a table object was closed but the reference wasn't reset, the other conditions didn't evaluate to true. With the addition of a new check on the error path, the handler started being dereferenced whenever it was not reset to NULL, causing problems for code paths which closed the table but didn't reset the reference. The solution is to reset the reference whenever a admin statement fails and the tables are closed. mysql-test/r/partition_innodb.result: Add test case result for Bug#54783 mysql-test/t/partition_innodb.test: Add test case for Bug#54783 sql/sql_table.cc: In case table recreate failed, set a appropriate result code. Reset reference to a closed table object, otherwise the error path might attempt to access it.
-
Alexander Nozdrin authored
-
- 05 Jul, 2010 5 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
3245 Vladislav Vaintroub 2010-06-16 Bug #52959 uint in typedef.h undefined on Windows Fix: change uint to "unsigned int"
-
Alexander Nozdrin authored
large-pages option is broken) from next-mr to trunk-bugfixing. Original revision: ------------------------------------------------------------ revision-id: vvaintroub@mysql.com-20100416134524-y4v27j90p5xvblmy parent: luis.soares@sun.com-20100416000700-n267ynu77visx31t committer: Vladislav Vaintroub <vvaintroub@mysql.com> branch nick: mysql-next-mr-bugfixing timestamp: Fri 2010-04-16 15:45:24 +0200 message: Bug #52716 Large files support is disabled, large-pages option is broken. Correct typo: large pages option was tied to wrong variable opt_large_files, instead of opt_large_pages. ------------------------------------------------------------
-
Sergey Vojtovich authored
Adjusted tests. mysql-test/r/information_schema.result: Adjusted tests. mysql-test/suite/funcs_1/r/is_engines_myisam.result: Adjusted tests.
-
Sergey Vojtovich authored
-
- 04 Jul, 2010 1 commit
-
-
Alfranio Correia authored
-
- 02 Jul, 2010 2 commits
-
-
Sergey Vojtovich authored
Fixed MyISAM storage engine comment, so it doesn't anymore state that MyISAM is default storage engine.
-
Alexander Nozdrin authored
-
- 01 Jul, 2010 1 commit
-
-
Luis Soares authored
DROP TEMP TABLE Cset: alfranio.correia@sun.com-20100420091043-4i6ouzozb34hvzhb introduced a change that made drop temporary table to be always logged if current statement log format was set to row. This is fine. However, logging operations, for a "DROP TABLE" statement in mysql_rm_table_part2, are not protected by first checking if the mysql_bin_log is open before proceeding to the actual logging. They only check the dont_log_query variable. This was actually uncovered by the aforementioned cset and not introduced by it. We fix this by extending the condition used in the "if" that wraps logging operations in mysql_rm_table_part2.
-
- 30 Jun, 2010 6 commits
-
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
-
Alfranio Correia authored
BUG#54872 MBR: replication failure caused by using tmp table inside transaction Changed criteria to classify a statement as unsafe in order to reduce the number of spurious warnings. So a statement is classified as unsafe when there is on-going transaction at any point of the execution if: 1. The mixed statement is about to update a transactional table and a non-transactional table. 2. The mixed statement is about to update a temporary transactional table and a non-transactional table. 3. The mixed statement is about to update a transactional table and read from a non-transactional table. 4. The mixed statement is about to update a temporary transactional table and read from a non-transactional table. 5. The mixed statement is about to update a non-transactional table and read from a transactional table when the isolation level is lower than repeatable read. After updating a transactional table if: 6. The mixed statement is about to update a non-transactional table and read from a temporary transactional table. 7. The mixed statement is about to update a non-transactional table and read from a temporary transactional table. 8. The mixed statement is about to update a non-transactionala table and read from a temporary non-transactional table. 9. The mixed statement is about to update a temporary non-transactional table and update a non-transactional table. 10. The mixed statement is about to update a temporary non-transactional table and read from a non-transactional table. 11. A statement is about to update a non-transactional table and the option variables.binlog_direct_non_trans_update is OFF. The reason for this is that locks acquired may not protected a concurrent transaction of interfering in the current execution and by consequence in the result. So the patch reduced the number of spurious unsafe warnings. Besides we fixed a regression caused by BUG#51894, which makes temporary tables to go into the trx-cache if there is an on-going transaction. In MIXED mode, the patch for BUG#51894 ignores that the trx-cache may have updates to temporary non-transactional tables that must be written to the binary log while rolling back the transaction. So we fix this problem by writing the content of the trx-cache to the binary log while rolling back a transaction if a non-transactional temporary table was updated and the binary logging format is MIXED.
-
Vladislav Vaintroub authored
mysqld-debug.exe in 5.5.3 on windows Fix: - Do not rename PDB, install mysqld.pdb matching mysqld-debug.exe into bin\debug subdirectory - Stack tracing code will now additionally look in debug subdirectory of the application directory for debug symbols. - Small cleanup in stacktracing code: link with dbghelp rather than load functions dynamically at runtime, since dbghelp.dll is always present. - Install debug binaries with WiX cmake/install_macros.cmake: Add optional COMPONENT and PDB_DESTINATION to INSTALL_DEBUG_TARGET mysys/stacktrace.c: If binary is build with DBUG, also look in debug subdirectory of executable directory. Packaging will put some PDBs there (e.g bin\mysqld-debug.exe will have corresponding pdb in bin\debug) Also some cleanup: do not load dbghelp dynamically, instead link with it. dbghelp is present on all Windows starting with XP. packaging/WiX/CPackWixConfig.cmake: Install debug binaries sql/CMakeLists.txt: Do not rename PDB for mysqld-debug.exe, install it in debug subdirectory
-
Alexander Nozdrin authored
-
- 29 Jun, 2010 1 commit
-
-
Luis Soares authored
switching binlog format to ROW BUG 52616 fixed the case which the user would switch from STMT to ROW binlog format, but the server would silently ignore it. After that fix thd->is_current_stmt_binlog_format_row() reports correct value at logging time and events are logged in ROW (as expected) instead of STMT as they were previously and wrongly logged. However, the fix was only partially complete, because on disconnect, at THD cleanup, the implicit logging of temporary tables is conditionally performed. If the binlog_format==ROW and thd->is_current_stmt_binlog_format_row() is true then DROPs are not logged. Given that the user can switch from STMT to ROW, this is wrong because the server cannot tell, just by relying on the ROW binlog format, that the tables have been dropped before. This is effectively similar to the MIXED scenario when a switch from STMT to ROW is triggered. We fix this by removing this condition from close_temporary_tables. mysql-test/extra/binlog_tests/drop_temp_table.test: Added binlog test case. mysql-test/suite/binlog/r/binlog_row_drop_tmp_tbl.result: Result changes because: - there is a missing drop on three temporary tables - it now contains results for the test added mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Result now contains the implicit drop for the temporary table. mysql-test/suite/binlog/r/binlog_stm_drop_tmp_tbl.result: Result file changed because it now contains results for added test case. mysql-test/suite/rpl/r/rpl_drop_temp.result: Result file changed because it now contains results for added test case. mysql-test/suite/rpl/t/rpl_drop_temp.test: Added replication test case. sql/sql_base.cc: Removed the condition that would make the server to skip logging implicit drops when ROW binary log format mode was in use. Additionally, deployed DBUG_ENTER/RETURN macros.
-
- 28 Jun, 2010 2 commits
-
-
Magne Mahre authored
This bug is a consequence of WL#5349, as the default storage engine was changed. The fix was to explicitly add an ENGINE clause to a CREATE TABLE statement, to ensure that we test case preservement on MyISAM.
-
Alexander Nozdrin authored
-
- 26 Jun, 2010 2 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 25 Jun, 2010 3 commits
-
-
Gleb Shchepa authored
-
Alexander Nozdrin authored
Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE The server crashed on an attempt to optimize a MERGE table with non-existent child table. mysql_admin_table() relied on the table to be successfully open if a table object had been allocated. Changed code to check return value of the open function before calling a handler:: function on it. mysql-test/r/merge.result: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE Updated result file. mysql-test/t/merge.test: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE Changed tests to respect changed TEMPORARY MERGE locking (unrelated). Changed tests to respect changed CREATE TABLE ... LIKE (unrelated). Changed tests to respect that no new tables can be created under LOCK TABLE (unrelated). Added test for Bug#47633. Changed error numbers to symbolic names. Added test for child locking for ALTER under LOCK TABLE. Since Bug 36171 is not pushed yet, not the whole patch has been backported. mysys/my_delete.c: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE Fixed error reporting. Fixed indentation. mysys/my_mmap.c: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE Added DBUG. sql/item_func.cc: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Added Debug Sync point, required by merge_sync.test. sql/sql_table.cc: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE Do not call handler:: functions if the table was not opened successfully. Added Debug Sync point, required by merge_sync.test. storage/myisam/mi_check.c: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Bug#47633 - assert in ha_myisammrg::info during OPTIMIZE Unmap memory before exchanging data files. Needed on Windows. storage/myisammrg/ha_myisammrg.cc: Backport of revid:ingo.struewing@sun.com-20091223200354-r2uzbdkj2v6yv111 Added Debug Sync point, required by merge_sync.test. merge_sync.test will be introduced by a patch for Bug 36171, which is not pushed yet.
-
Jon Olav Hauglid authored
DML flow and SAVEPOINT The problem was that replication could break if a transaction involving both transactional and non-transactional tables was rolled back to a savepoint. It broke if a concurrent connection tried to drop a transactional table which was locked after the savepoint was set. This DROP TABLE completed when ROLLBACK TO SAVEPOINT was executed as the lock on the table was dropped by the transaction. When the slave later tried to apply the binlog, it would fail as the table would already have been dropped. The reason for the problem is that transactions involving both transactional and non-transactional tables are written fully to the binlog during ROLLBACK TO SAVEPOINT. At the same time, metadata locks acquired after a savepoint, were released during ROLLBACK TO SAVEPOINT. This allowed a second connection to drop a table only used between SAVEPOINT and ROLLBACK TO SAVEPOINT. Which caused the transaction binlog to refer to a non-existing table when it was written during ROLLBACK TO SAVEPOINT. This patch fixes the problem by not releasing metadata locks when ROLLBACK TO SAVEPOINT is executed if binlogging is enabled.
-
- 24 Jun, 2010 1 commit
-
-
Luis Soares authored
Problem: SQL and IO thread were racing for the IO_CACHE. The former to flush it, the latter to close it. In some cases this would cause the SQL thread to lock an invalid IO_CACHE mutex (it had been destroyed by IO thread). This would happen when SQL thread was initializing the master.info Solution: We solve this by locking the log and checking if it is hot. If it is we keep the log while seeking. Otherwise we release it right away, because a log can get from hot to cold, but not from cold to hot.
-