1. 17 Sep, 2009 4 commits
    • Staale Smedseng's avatar
      Merge from 5.0 · 5051100a
      Staale Smedseng authored
      5051100a
    • Staale Smedseng's avatar
      Bug #43414 Parenthesis (and other) warnings compiling MySQL · 38b6d49e
      Staale Smedseng authored
      with gcc 4.3.2
            
      This is the fifth patch cleaning up more GCC warnings about
      variables used before initialized using the new macro
      UNINIT_VAR().
      38b6d49e
    • Sergey Glukhov's avatar
      Bug#42364 SHOW ERRORS returns empty resultset after dropping non existent table · 4d6bf3ce
      Sergey Glukhov authored
      additional backport of of bug43138 fix
      4d6bf3ce
    • Satya B's avatar
      Applying InnoDB snapshot 5.1-ss5282, Fixes BUG#44030 · 0b8243cb
      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.
      0b8243cb
  2. 16 Sep, 2009 2 commits
  3. 15 Sep, 2009 2 commits
  4. 13 Sep, 2009 2 commits
    • Luis Soares's avatar
      BUG#47016: rpl_do_grant fails on PB-2 with a failing connect · 09f07bc1
      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.
      09f07bc1
    • Luis Soares's avatar
      BUG#47014: rpl_drop_temp fails on PB-2 with results mismatch · 4cce928e
      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.
      4cce928e
  5. 11 Sep, 2009 2 commits
  6. 10 Sep, 2009 11 commits
  7. 09 Sep, 2009 5 commits
  8. 08 Sep, 2009 2 commits
  9. 07 Sep, 2009 7 commits
  10. 05 Sep, 2009 1 commit
    • Alexey Kopytov's avatar
      Bug #46159: simple query that never returns · f1617238
      Alexey Kopytov authored
       
      The external 'for' loop in remove_dup_with_compare() handled 
      HA_ERR_RECORD_DELETED by just starting over without advancing 
      to the next record which caused an infinite loop. 
       
      This condition could be triggered on certain data by a SELECT 
      query containing DISTINCT, GROUP BY and HAVING clauses. 
      
      Fixed remove_dup_with_compare() so that we always advance to 
      the next record when receiving HA_ERR_RECORD_DELETED from 
      rnd_next(). 
      f1617238
  11. 04 Sep, 2009 2 commits