- 18 Oct, 2010 1 commit
-
-
Vasil Dimov authored
In order to fix this bug we need to distinguish whether ha_innobase::info() has been called from ::analyze() or not. Rename ::info() to ::info_low() and add a boolean parameter that tells whether the call is from ::analyze() or not. Create a new simple ::info() that just calls ::info_low(false => not called from analyze). From ::analyze() instead of ::info() call ::info_low(true => called from analyze). Approved by: Jimmy (rb://487)
-
- 15 Oct, 2010 4 commits
-
-
Vasil Dimov authored
It was added in jimmy.yang@oracle.com-20100902004302-m5ax9qo0ne2msdfx
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Vasil Dimov authored
-
- 14 Oct, 2010 3 commits
-
-
Jimmy Yang authored
-
Vasil Dimov authored
Tune the test for Bug#56143 too many foreign keys causes output of show create table to become invalid Use a CREATE statement with all the FKs instead of ALTERing the table many times because it is faster (11 seconds vs 3 seconds).
-
Vasil Dimov authored
This is a port of the following changeset from 5.1/storage/innobase to 5.1/storage/innodb_plugin: ------------------------------------------------------------ revno: 3626 revision-id: vasil.dimov@oracle.com-20101013171859-gi9n558yj89x9v3w parent: klewis@mysql.com-20101012175933-ce9kkgl0z8oeqffa committer: Vasil Dimov <vasil.dimov@oracle.com> branch nick: mysql-5.1-innodb timestamp: Wed 2010-10-13 20:18:59 +0300 message: Fix Bug#56143 too many foreign keys causes output of show create table to become invalid Just remove the check whether the file is "too big". A similar code exists in ha_innobase::update_table_comment() but that method does not seem to be used. Also use a CREATE statement with all the FKs instead of ALTERing the table 550 times because it is faster.
-
- 13 Oct, 2010 1 commit
-
-
Vasil Dimov authored
Just remove the check whether the file is "too big". A similar code exists in ha_innobase::update_table_comment() but that method does not seem to be used.
-
- 14 Oct, 2010 1 commit
-
-
Jimmy Yang authored
rb://483 approved by Inaam
-
- 13 Oct, 2010 4 commits
-
-
unknown authored
-
Luis Soares authored
latest mysql-5.1-bugteam.
-
Luis Soares authored
latest mysql-5.1-bugteam.
-
Dmitry Shulga authored
mysql-test/r/grant.result: It was added result for test case for bug#36742. mysql-test/t/grant.test: It was added test case for bug#36742. sql/sql_yacc.yy: It was added convertation of host name part of user name to lowercase.
-
- 12 Oct, 2010 1 commit
-
-
unknown authored
Bug#56632 - The warning code related to KEY_BLOCK_SIZE and ROW_FORMAT when innodb_strict_mode=OFF is improved in order to take into account whether the KEY_BLOCK_SIZE is specified on the current ALTER statement or the previous CREATE statement. The testcase shows the expected results of 12 different combinations of these settings.
-
- 11 Oct, 2010 3 commits
-
-
Jimmy Yang authored
with concurrent lock/unlock tables Approved by Marko
-
unknown authored
After ALTER TABLE which changed only table's metadata, row-based binlog sometimes got corrupted since the tablemap was unexpectedly set to 0 for subsequent updates to the same table. ALTER TABLE which changed only table's metadata always reset table_map_id for the table share to 0. Despite the fact that 0 is a valid value for table_map_id, this step caused problems as it could have created situation in which we had more than one table share with table_map_id equal 0. If more than one table with table_map_id are 0 were updated in the same statement, updates to these different tables were written into the same rows event. This caused slave server to crash. This bug happens only on 5.1. It doesn't affect 5.5+. This patch solves this problem by ensuring that ALTER TABLE statements which change metadata only never reset table_map_id to 0. To do this it changes reopen_table() to correctly use refreshed table_map_id value instead of using the old one/ resetting it. mysql-test/suite/rpl/r/rpl_alter.result: Add test for BUG#56226 mysql-test/suite/rpl/t/rpl_alter.test: Add test for BUG#56226
-
Sunny Bains authored
Print an error message to stderr an get rid of the assertion. Approved by: Jimmy Yang (over IM)
-
- 10 Oct, 2010 1 commit
-
-
Alfranio Correia authored
-
- 09 Oct, 2010 1 commit
-
-
unknown authored
When slave executes a transaction bigger than slave's max_binlog_cache_size, slave will crash. It is caused by the assert that server should only roll back the statement but not the whole transaction if the error ER_TRANS_CACHE_FULL happens. But slave sql thread always rollbacks the whole transaction when an error happens. Ather this patch, we always clear any error set in sql thread(it is different from the error in 'SHOW SLAVE STATUS') and it is cleared before rolling back the transaction. mysql-test/suite/rpl/r/rpl_binlog_max_cache_size.result: SET binlog_cache_size and max_binlog_cache_size for all test cases. Add test case for bug#55375. mysql-test/suite/rpl/t/rpl_binlog_max_cache_size-master.opt: binlog_cache_size and max_binlog_cache_size can be set in the client connection. so remove this option file. mysql-test/suite/rpl/t/rpl_binlog_max_cache_size.test: SET binlog_cache_size and max_binlog_cache_size for all test cases. Add test case for bug#55375. sql/log_event.cc: Some functions don't return the error code, so it is a wrong error code. The error should always be set into thd->main_da. So we use slave_rows_error_report to report the right error. sql/slave.cc: exec_relay_log_event() need call cleanup_context() to clear context. clearup_context() will call end_trans(). Clear thd's error before cleanup_context. It avoid to trigger the assert which cause this bug.
-
- 07 Oct, 2010 1 commit
-
-
Martin Hansson authored
This is a regression from the fix for bug no 38999. A storage engine capable of reading only a subset of a table's columns updates corresponding bits in the read buffer to signal that it has read NULL values for the corresponding columns. It cannot, and should not, update any other bits. Bug no 38999 occurred because the implementation of UPDATE statements compare the NULL bits using memcmp, inadvertently comparing bits that were never requested from the storage engine. The regression was caused by the storage engine trying to alleviate the situation by writing to all NULL bits, even those that it had no knowledge of. This has devastating effects for the index merge algorithm, which relies on all NULL bits, except those explicitly requested, being left unchanged. The fix reverts the fix for bug no 38999 in both InnoDB and InnoDB plugin and changes the server's method of comparing records. For engines that always read entire rows, we proceed as usual. For engines capable of reading only select columns, the record buffers are now compared on a column by column basis. An assertion was also added so that non comparable buffers are never read. Some relevant copy-pasted code was also consolidated in a new function.
-
- 06 Oct, 2010 2 commits
-
-
Luis Soares authored
Suprisingly, a Slave_log_event would show up in the binary log. This event is never used and should not appear in the logs. As such, when the slave (or the mysqlbinlog tool) reads the event, it will hit an invalid pointer (reference to the descriptor event when deserializing the Slave_log_event was purposodely set to NULL). The presence of the Slave_log_event denotes a corrupted log, but we cannot tell how the log got corrupted in the first place. However, we can make the server cope with such events when it reads them - in case of log corruption - and fail gracefully. This patch makes the server/mysqlbinlog to report that it has found an invalid log event when Slave_log_event is read.
-
Alfranio Correia authored
Backported the patch for BUG#55452.
-
- 05 Oct, 2010 9 commits
-
-
Vasil Dimov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 04 Oct, 2010 4 commits
-
-
Vasil Dimov authored
-
Marko Mäkelä authored
row_search_for_mysql(): Acquire an intention lock on the table before locking the first record gap.
-
Marko Mäkelä authored
row_search_for_mysql(): Acquire an intention lock on the table before locking the first record gap.
-
Vasil Dimov authored
-
- 03 Oct, 2010 2 commits
-
-
Bjorn Munch authored
-
Bjorn Munch authored
-
- 01 Oct, 2010 2 commits
-
-
Alexey Kopytov authored
-
Mattias Jonsson authored
-