1. 18 Feb, 2013 6 commits
  2. 16 Feb, 2013 2 commits
    • Shivji Kumar Jha's avatar
      BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2, · ba91ca7d
      Shivji Kumar Jha authored
                    PLATFORM= MACOSX10.6 X86_64 MAX
      
      bzr merge 5.1=>5.5
      ba91ca7d
    • Shivji Kumar Jha's avatar
      BUG#15965353- RPL.RPL_ROW_UNTIL FAILS ON PB2, · 71e9e948
      Shivji Kumar Jha authored
                    PLATFORM= MACOSX10.6 X86_64 MAX
      
      Problem: The test was failing on pb2's mac machine because
               it was not cleaned up properly. The test checks if
               the command 'start slave until' throws a proper
               error when issued with a wrong number/type of
               parameters. After this,the replication stream was
               stopped using the include file 'rpl_end.inc'.
               The errors thrown earlier left the slave in an
               inconsistent state to be closed by the include
               file which was caught by the mac machine.
      
      Fix: Started slave by invoking start_slave.inc to have a
           working slave before calling rpl_reset.inc
      
      Problem: The test file was not in a good shape. It tested
               start slave until relay log file/pos combination 
               wrongly. A couple of commands were executed at 
               master and replicated at slave. Next, the 
               coordinates in terms of relay log file and pos 
               were noted down followed by reset slave and start
               slave until saved relay log file/pos. Reset slave
               deletes  all relay log files and makes the slave 
               forget its replication position. So, using the 
               saved coordiantes after reset slave is wrong.
      
      Fix: Split the test in two parts:
           a) Test for start slave until master log file/pos and
              checking for correct errors in the failure 
              scenarios.
           b) Test for start slave until relay log file/pos.
      
      Problem: The variables auto_increment_increment and 
               auto_increment_offset were set in the the include
               file rpl_init.inc. This was only configured for 
               some connections that are rarely used by test 
               cases, so likely that it will cause confusion. 
               If replication tests want to setup these variables
               they should do so explicitly.
      
      Fix:
           a) Removed code to set the variables
              auto_increment_increment and auto_increment_offset
              in the include file.
           b) Updated tests files using the same.
      71e9e948
  3. 15 Feb, 2013 5 commits
    • Pedro Gomes's avatar
      BUG#13545447: RPL_ROTATE_LOGS FAILS DUE TO CONCURRENCY ISSUES IN REP. CODE · 552f1f4b
      Pedro Gomes authored
      Merge from mysql 5.1 to mysql 5.5
      552f1f4b
    • Pedro Gomes's avatar
      BUG#13545447: RPL_ROTATE_LOGS FAILS DUE TO CONCURRENCY ISSUES IN REP. CODE · 80699f32
      Pedro Gomes authored
      In method mysql_binlog_send, right after detecting a EOF in the
      read event loop, and before deciding if we should change to a new
      binlog file there is a execution window where new events can be
      written to the binlog and a rotation can happen. When reaching
      the test, the function will then change to a new binlog file
      ignoring all the events written in this window. This will result
      in events not being replicated.
      
      Only when the binlog is detected as deactivated in the event loop
      of the dump thread, can we really know that no more events
      remain. For this reason, this test is now made under the log lock
      in the beginning of the event loop when reading the events.
      80699f32
    • Alexander Nozdrin's avatar
      Bug#16056537: MYSQLD CRASHES IN ITEM_FUNC_GET_USER_VAR::FIX_LENGTH_AND_DEC() · 49b29688
      Alexander Nozdrin authored
      The technical problem was that THD::user_var_events_alloc was reset to NULL
      from a valid value when a stored program is executed during the PREPARE statement.
      
      The user visible problem was that the server crashed if user issued a PREPARE
      statement using some combination of stored functions and user variables.
      
      The fix is to restore THD::user_var_events_alloc to the original value.
      This is a minimal fix for 5.5.
      
      More proper patch has been already implemented for 5.6+. It avoids
      evaluation of stored functions for the PREPARE phase.
      
      From the user point of view, this bug is a regression, introduced by the patch for WL2649
      (Number-to-string conversions), revid: bar@mysql.com-20100211041725-ijbox021olab82nv
      However, the code resetting THD::user_var_events_alloc exists even in 5.1.
      The WL just changed the way arguments are converted to strings and the bug became visible.
      49b29688
    • Harin Vadodaria's avatar
      Bug#16218104: MYSQL YASSL - LUCKY THIRTEEN: BREAKING THE · d6fca3e3
      Harin Vadodaria authored
                    TLS AND DTLS RECORD PROTOCOLS
      
      Description: Merge from 5.1.
      d6fca3e3
    • Harin Vadodaria's avatar
      Bug#16218104: MYSQL YASSL - LUCKY THIRTEEN: BREAKING THE · c13f4a71
      Harin Vadodaria authored
                    TLS AND DTLS RECORD PROTOCOLS
      
      Description: In yassl, decryption phase in TLS protocol
                   depends on type of padding. This patch
                   removes this dependancy and makes error
                   generation/decryption process independent
                   of padding type.
      c13f4a71
  4. 14 Feb, 2013 5 commits
    • Shivji Kumar Jha's avatar
      BUG#12359942- REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT · a44b3a0f
      Shivji Kumar Jha authored
            
      post push fix: 
      rpl_stm_until.test was disabled because of
      this bug. Enabled and fixed it.
      
      Removed a part of the test that was obsolete.
      It tested replication from 4.0 master to 5.0
      slave.
      a44b3a0f
    • Shivji Kumar Jha's avatar
      BUG#12359942- REPLICATION TEST FROM ENGINE SUITE RPL_ROW_UNTIL TIMES OUT · c7745152
      Shivji Kumar Jha authored
            
      post push fix: 
      rpl_stm_until.test was disabled because of
      this bug. Enabled and fixed it.
      
      Removed a part of the test that was obsolete.
      It tested replication from 4.0 master to 5.0
      slave.
      c7745152
    • Mattias Jonsson's avatar
      Bug#16274455: CAN NOT ACESS PARTITIONED TABLES WHEN · 89681f6d
      Mattias Jonsson authored
      DOWNGRADED FROM 5.6.11 TO 5.6.10
      
      Problem was new syntax not accepted by previous version.
      
      Fixed by adding version comment of /*!50531 around the
      new syntax.
      
      Like this in the .frm file:
      'PARTITION BY KEY /*!50611 ALGORITHM = 2 */ () PARTITIONS 3'
      and also changing the output from SHOW CREATE TABLE to:
      CREATE TABLE t1 (a INT)
      /*!50100 PARTITION BY KEY */ /*!50611 ALGORITHM = 1 */ /*!50100 ()
      PARTITIONS 3 */
      
      It will always add the ALGORITHM into the .frm for KEY [sub]partitioned
      tables, but for SHOW CREATE TABLE it will only add it in case it is the non
      default ALGORITHM = 1.
      
      Also notice that for 5.5, it will say /*!50531 instead of /*!50611, which
      will make upgrade from 5.5 > 5.5.31 to 5.6 < 5.6.11 fail!
      If one downgrades an fixed version to the same major version (5.5 or 5.6) the
      bug 14521864 will be visible again, but unless the .frm is updated, it will
      work again when upgrading again.
      
      Also fixed so that the .frm does not get updated version
      if a single partition check passes.
      89681f6d
    • Annamalai Gurusami's avatar
      Merge from mysql-5.1 to mysql-5.5 · c0333739
      Annamalai Gurusami authored
      c0333739
    • Annamalai Gurusami's avatar
      For the error code ER_TOO_LONG_IDENT, the identifier is expected in the... · 753eadb2
      Annamalai Gurusami authored
      For the error code ER_TOO_LONG_IDENT, the identifier is expected in the my_error call.  So removing this line from here.  
      753eadb2
  5. 12 Feb, 2013 2 commits
  6. 08 Feb, 2013 4 commits
  7. 07 Feb, 2013 3 commits
  8. 06 Feb, 2013 1 commit
  9. 05 Feb, 2013 2 commits
  10. 04 Feb, 2013 2 commits
  11. 08 Feb, 2013 3 commits
  12. 07 Feb, 2013 3 commits
  13. 06 Feb, 2013 2 commits
    • kevin.lewis@oracle.com's avatar
      Bug#16263506 - INNODB; USE ABORT() ON ALL PLATFORMS INSTEAD OF · f3bfae1b
      kevin.lewis@oracle.com authored
                     DEREFERENCING UT_DBG_NULL_PTR
      The abort() call is standard C but InnoDB only uses it in GCC
      environments.  UT_DBG_USE_ABORT is not defined the code crashed
      by dereferencing a null pointer instead of calling abort().
      Other code throughout MySQL including ndb, sql, mysys and other
      places call abort() directly.
      
      This bug also affects innodb.innodb_bug14147491.test which fails
      randomly on windows because of this issue. 
      
      Approved by marko in http://rb.no.oracle.com/rb/r/1936/
      f3bfae1b
    • Ravinder Thakur's avatar
      Bug#14711808 MSI INSTALLATION / UPGRADE CAN CORRUPT EXISTING INSTALLATION · cc1a0d2a
      Ravinder Thakur authored
      Currently MySQL MSI installer on Windows installs MySQL in 
      "per user" mode. It means that if a Windows machine has 
      multiple users, they each can install MySQL independently. 
      However the default path of MySQL is "C:\Program Files (x86)\MySQL\"
      and when two users install MySQL on same machine, the installation
      by second user just overwrites the MySQL files. This default shared 
      location leads to the issue where if the second user uninstalls MySQL,
      the installation files are removed for the first user as well.
      
      In this fix, we are now making the default installation "per machine".
      It means that when MySQL is installed with defaults options, all
      users can see the shortcuts for MySQL in start menu(since installations 
      is for all users). Also when any user relaunches the installer, it will 
      consider that action uninstallation rather than installation for that user.
      
      There are command line options in installer that can be used to undo the
      "per machine" installation but will not consider that scenario.MySQL 
      is a server product and it does not make a lot of sense to install it
      differently for each user.
      cc1a0d2a