- 05 Oct, 2009 1 commit
-
-
Bjorn Munch authored
-
- 02 Oct, 2009 1 commit
-
-
Bjorn Munch authored
Alt. solution: let the "InnoDB plugin" combinations apply Added some alternative plugin paths (I need to move the code anyway)
-
- 23 Sep, 2009 8 commits
-
-
Bjorn Munch authored
-
Bjorn Munch authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Bjorn Munch authored
-
Alexander Nozdrin authored
-
- 22 Sep, 2009 4 commits
-
-
Bjorn Munch authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Bjorn Munch authored
-
- 21 Sep, 2009 3 commits
-
-
Jonathan Perkin authored
-
Bjorn Munch authored
-
Bjorn Munch authored
-
- 19 Sep, 2009 4 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 18 Sep, 2009 5 commits
-
-
Alexander Nozdrin authored
-
Bjorn Munch authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
After discussion with Satya this bug does not exist in trunk.
-
- 17 Sep, 2009 4 commits
-
-
Alexander Nozdrin authored
-
Joerg Bruehe authored
-
Sergey Glukhov authored
additional backport of of bug43138 fix
-
Satya B authored
1. Fixes BUG#44030 - Error: (1500) Couldn't read the MAX(ID) autoinc value from the index (PRIMARY) 2. Disables the innodb-autoinc test for innodb plugin temporarily. The testcase for this bug has different result file for InnoDB plugin. Should add the testcase to Innodb suite with a different result file. Detailed revision comments: r5243 | sunny | 2009-06-04 03:17:14 +0300 (Thu, 04 Jun 2009) | 14 lines branches/5.1: When the InnoDB and MySQL data dictionaries go out of sync, before the bug fix we would assert on missing autoinc columns. With this fix we allow MySQL to open the table but set the next autoinc value for the column to the MAX value. This effectively disables the next value generation. INSERTs will fail with a generic AUTOINC failure. However, the user should be able to read/dump the table, set the column values explicitly, use ALTER TABLE to set the next autoinc value and/or sync the two data dictionaries to resume normal operations. Fix Bug#44030 Error: (1500) Couldn't read the MAX(ID) autoinc value from the index (PRIMARY) rb://118 r5252 | sunny | 2009-06-04 10:16:24 +0300 (Thu, 04 Jun 2009) | 2 lines branches/5.1: The version of the result file checked in was broken in r5243. r5259 | vasil | 2009-06-05 10:29:16 +0300 (Fri, 05 Jun 2009) | 7 lines branches/5.1: Remove the word "Error" from the printout because the mysqltest suite interprets it as an error and thus the innodb-autoinc test fails. Approved by: Sunny (via IM) r5466 | vasil | 2009-07-02 10:46:45 +0300 (Thu, 02 Jul 2009) | 6 lines branches/5.1: Adjust the failing innodb-autoinc test to conform to the latest behavior of the MySQL code. The idea and the comment in innodb-autoinc.test come from Sunny.
-
- 16 Sep, 2009 5 commits
-
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Ingo Struewing authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
- 15 Sep, 2009 2 commits
-
-
Kristofer Pettersson authored
-
Kristofer Pettersson authored
-
- 13 Sep, 2009 2 commits
-
-
Luis Soares authored
The test case rpl_do_grant fails sporadically on PB2 with "Access denied for user 'create_rout_db'@'localhost' ...". Inspecting the test case, one may find that if issues a GRANT on the master connection and immediately after it creates two new connections (one to the master and one to the slave) using the credentials set with the GRANT. Unfortunately, there is no synchronization between master and slave after the grant and before the connections are established. This can result in slave not having executed the GRANT by the time the connection is attempted. This patch fixes this by deploying a sync_slave_with_master between the grant and the connections attempt.
-
Luis Soares authored
The test case creates two temporary tables, then closes the connection, waits for it to disconnect, then syncs the slave with the master, checks for remaining opened temporary tables on slave (which should be 0) and finally drops the used database (mysqltest). Unfortunately, sometimes, the test fails with one open table on the slave. This seems to be caused by the fact that waiting for the connection to be closed is not sufficient. The test needs to wait for the DROP event to be logged and only then synchronize the slave with the master and proceed with the check. This is caused by the asynchronous nature of the disconnect wrt binlogging of the DROP temporary table statement. We fix this by deploying a call to wait_for_binlog_event.inc on the test case, which makes execution to wait for the DROP temp tables event before synchronizing master and slave.
-
- 11 Sep, 2009 1 commit
-
-
Mattias Jonsson authored
-