1. 16 Jan, 2015 1 commit
  2. 15 Jan, 2015 1 commit
    • Jon Olav Hauglid's avatar
      Bug#20344207: Add support for CMake 3.1 · 2750b4b7
      Jon Olav Hauglid authored
      Rename a CMake variable in compile_flags.cmake to avoid triggering
      CMake 3.1 warning about CMP0054 about interpreting if() arguments
      as keywords or variables.
      
      No changes in behavior.
      2750b4b7
  3. 14 Jan, 2015 3 commits
    • Bala's avatar
      Updated file_contents test for sles packages · e84b3fd4
      Bala authored
      e84b3fd4
    • Venkatesh Duggirala's avatar
      Problem: IO thread fails to connect to master if servers are configured with · ebb2a3f5
      Venkatesh Duggirala authored
      special character sets like utf16, utf32, ucs2.
      
      Analysis: MySQL server does not support few special character sets like
        utf16,utf32 and ucs2 as "client's character set"(eg: utf16,utf32, ucs2).
        It is known limitation listed in the documentation
        http://dev.mysql.com/doc/refman/5.5/en/charset-connection.html.
      
        The default value for default-character-set parameter is 'auto'
        which means that if the server's character set is not supported,
        then server automatically changes client's character set to
        predefined character-set which is 'latin1' in the current code.
      
        Eg:
        $ ./mysql -uroot -S$SOCKET_FILE --default-character-set=utf16
        ERROR 1231 (42000): Variable 'character_set_client' can't be set to the value of 'utf16'
      
        $ ./mysql -uroot -S$SOCKET_FILE will be successfully connected to
        server with 'latin1' as default client side character set.
      
        When IO thread is trying to connect to Master, it sets server's character
        set as client's character set. When Slave server is started with these
        special character sets, IO thread (which is like a connection to Master)
        fails because of the above said limitation.
      
       Fix: Now even IO thread also behaves the same as a regular client behaves.
        i.e., If server's character set is not supported as client's character set,
        then set default's client character set(latin1) as client's character set.
      ebb2a3f5
    • Praveenkumar.Hulakund's avatar
      Bug#19786309 - CRASH IN UNLOCK TABLES AFTER LOCKING AND TRUNCATING TEMPORARY TABLE. · 23321f62
      Praveenkumar.Hulakund authored
      Attempt to truncate temporary table using Blackhole storage and
      locked by LOCK TABLES caused assertion failure and crashes.
      
      Blackhole is a transaction-aware engine. While creating the temporary
      table in transaction-aware engine, temporary table of type
      "TRANSACTIONAL_TMP_TABLE" is created. For such temporary tables
      a THR_LOCK lock is acquired by the LOCK TABLE operation. References
      to them are also added into MYSQL_LOCK::table[] array. Also for
      Blackhole engine, flag HTON_CAN_RECREATE is set.
      
      While truncating temporary tables, no locks are taken and
      recreate_temporary_table() is called for engines having
      "HTON_CAN_RECREATE" in flag.
      
      Function closefrm() is called from the recreate_temporary_table(),
      to close the current temporary table. In closefrm(), the lock on
      table expected is "F_UNLCK". In debug builds, assert condition on
      this fails when lock of type "F_WRLCK" is acquired by LOCK TABLE
      operation on temporary tables using Blackhole engine.
      
      In non-debug builds closefrm() simply freed TABLE object leaving
      dangling pointer to this object in MYSQL_LOCK::table[] array which
      might lead to crashes later.
      
      Fix:
      ---------
      To fix this issue, we now unlock and remove table from MYSQL_LOCK::table[]
      array before calling close_temporary_table() in recreate_temporary_table().
      This is achieved by calling mysql_lock_remove() function for this table.
      23321f62
  4. 05 Jan, 2015 1 commit
  5. 02 Jan, 2015 1 commit
  6. 30 Dec, 2014 1 commit
    • Harin Vadodaria's avatar
      Bug#20201864 : UPGRADE TO YASSL 2.3.7 · 3ce85548
      Harin Vadodaria authored
      Upgrading YaSSL from 2.3.5 to 2.3.7
      
      Reviewed-by : Kristofer Pettersson <kristofer.pettersson@oracle.com>
      Reviewed-by : Vamsikrishna Bhagi <vamsikrishna.bhagi@oracle.com>
      3ce85548
  7. 29 Dec, 2014 1 commit
    • s.sujatha's avatar
      Bug#20041860: SLAVE ERROR WHEN DROP DATABASE · 5da083ef
      s.sujatha authored
      Fix:
      ===
      Backport Bug#11756194 to mysql-5.5. slave breaks if
      'drop database' fails on master and mismatched tables on
      slave.
      
      'DROP TABLE <deleted tables>' was binlogged when
      'DROP DATABASE' failed and at least one table was deleted
      from the database. The log event would lead slave SQL thread
      stop if some of the tables did not exist on slave.
      
      After this patch, It is always binlogged with 'IF EXISTS'
      option.
      5da083ef
  8. 24 Dec, 2014 1 commit
    • Thiru's avatar
      Bug #20144839 AFTER UPDATING TO MYSQL 5.6.22 SERVER · 901ce531
      Thiru authored
      		CRASHES ON EVERY START ATTEMPT
      
      Description:
      ------------
      push_warning_printf function is used to print the warning message
      to the client. So this function should not invoke while recovering
      the server. Moreover current_thd is NULL while starting the server.
      
      Solution:
      ---------
       - Avoiding the warning to be printed while recovery.
      This patch already pushed in mysql-5.6.
      901ce531
  9. 22 Dec, 2014 1 commit
  10. 11 Dec, 2014 1 commit
  11. 09 Dec, 2014 1 commit
  12. 05 Dec, 2014 1 commit
  13. 03 Dec, 2014 1 commit
    • Vamsikrishna Bhagi's avatar
      Bug #19688008 CREATE_ASYMMETRIC_PUB_KEY: CRASHES IN OPENSSL · cb9d0deb
      Vamsikrishna Bhagi authored
                    CODE
      
      Problem: UDF doesn't handle the arguments properly when they
               are of string type due to a misplaced break.
               The length of arguments is also not set properly
               when the argument is NULL.
      
      Solution: Fixed the code by putting the break at right place
                and setting the argument length to zero when the
                argument is NULL.
      cb9d0deb
  14. 28 Nov, 2014 2 commits
  15. 26 Nov, 2014 1 commit
    • V S Murthy Sidagam's avatar
      Bug #16869534 QUERYING SUBSET OF COLUMNS DOESN'T USE TABLE CACHE; OPENED_TABLES I · aed8369e
      V S Murthy Sidagam authored
      Description: When querying a subset of columns from the information_schema.TABLES
      
      Analysis: When information about tables is collected for statements like
      "SELECT ENGINE FROM I_S.TABLES" we do not perform full-blown table opens
      in SE, instead we only use information from table shares from the Table
      Definition Cache or .FRMs. Still in order to simplify I_S implementation
      mock TABLE objects are created from TABLE_SHARE during this process.
      This is done by calling open_table_from_share() function with special
      arguments. Since this function always increments "Opened_tables" counter,
      calls to it can be mistakingly interpreted as full-blown table opens in SE.
      
      Note that claim that "'SELECT ENGINE FROM I_S.TABLES' statement doesn't
      use Table Cache" is nevertheless factually correct. But it misses the
      point, since such statements a) don't use full-blown TABLE objects and
      therefore don't do table opens b) still use Table Definition Cache.
      
      Fix: We are now incrementing the counter when db_stat(i.e open flags for ha_open(
      
      we have considered an optimization which would use TABLE objects from
      Table Cache when available instead of constructing mock TABLE objects,
      but found it too intrusive for stable releases.
      aed8369e
  16. 24 Nov, 2014 1 commit
    • Nisha Gopalakrishnan's avatar
      BUG#11747548: DETECT ORPHAN TEMP-POOL FILES, AND HANDLE GRACEFULLY · 5a587b6d
      Nisha Gopalakrishnan authored
      Analysis:
      --------
      Certain queries using intrinsic temporary tables may fail due to
      name clashes in the file name for the temporary table when the
      'temp-pool' enabled.
      
      'temp-pool' tries to reduce the number of different filenames used for
      temp tables by allocating them from small pool in order to avoid
      problems in the Linux kernel by using a three part filename:
      <tmp_file_prefix>_<pid>_<temp_pool_slot_num>.
      The bit corresponding to the temp_pool_slot_num is set in the bit
      map maintained for the temp-pool when it used for the file name.
      It is cleared after the temp table is deleted for re-use.
      
      The 'create_tmp_table()' function call under error condition
      tries to clear the same bit twice by calling 'free_tmp_table()'
      and 'bitmap_lock_clear_bit()'. 'free_tmp_table()' does a delete
      of the table/file and clears the bit by calling the same function
      'bitmap_lock_clear_bit()'.
      
      The issue reported can be triggered under the timing window mentioned
      below for an error condition while creating the temp table:
      a) THD1: Due to an error clears the temp pool slot number used by it
         by calling 'free_tmp_table'.
      b) THD2: In the process of creating the temp table by using an unused
         slot number in the bit map.
      c) THD1: Clears the slot number used THD2 by calling
        'bitmap_lock_clear_bit()' after completing the call 'free_tmp_table'.
      d) THD3: Uses the slot number used the THD2 since it is freed by THD1.
         When it tries to create the temp file using that slot number,
         an error is reported since it is currently in use by THD2.
         [The error: Error 'Can't create/write to file
         '/tmp/#sql_277e_0.MYD' (Errcode: 17)']
      
      Another issue which may occur in 5.6 and trunk is that:
      When the open temporary table fails after its creation(due to ulimit
      or OOM error), the file is not deleted. Thus further attempts to use
      the same slot number in the 'temp-pool' results in failure.
      
      Fix:
      ---
      a) Under the error condition calling the 'bitmap_lock_clear_bit()'
         function to clear the bit is unnecessary since 'free_tmp_table()'
         deletes the table/file and clears the bit. Hence removed the
         redundant call 'bitmap_lock_clear_bit()' in 'create_tmp_table()'
         This prevents the timing window under which the issue reported
         can be seen.
      
      b) If open of the temporary table fails, then the file is deleted
         thus allowing the temp-pool slot number to be utilized for the
         subsequent temporary table creation.
      
      c) Also if the attempt to create temp table fails since it already
         exists, the temp-pool slot for it is marked as used, to avoid
         the problem from re-appearing.
      5a587b6d
  17. 17 Nov, 2014 1 commit
  18. 12 Nov, 2014 1 commit
  19. 11 Nov, 2014 2 commits
  20. 10 Nov, 2014 1 commit
    • Arun Kuruvila's avatar
      Bug#17599258:- ERROR 1160 (08S01): GOT AN ERROR WRITING · a9b61b00
      Arun Kuruvila authored
                     COMMUNICATION PACKETS; FEDERATED TABLE
      
      Description:- Execution of FLUSH TABLES on a federated
      table which has been idle for wait_timeout (on the remote
      server) + tcp_keepalive_time, fails with an error,
      "ERROR 1160 (08S01): Got an error writing communication
      packets."
      
      Analysis:- During FLUSH TABLE execution the federated
      table is closed which will inturn close the federated
      connection. While closing the connection, federated server
      tries to communincate with the remote server. Since the
      connection was idle for wait_timeout(on the remote server)+
      tcp_keepalive_time, the socket gets closed. So this
      communication fails because of broken pipe and the error is
      thrown. But federated connections are expected to reconnect
      silently. And also it cannot reconnect because the 
      "auto_reconnect" variable is set to 0 in "mysql_close()".
      
      Fix:- Before closing the federated connection, in
      "ha_federated_close()", a check is added which will verify
      wheather the connection is alive or not. If the connection
      is not alive, then "mysql->net.error" is set to 2 which
      will indicate that the connetion is broken. Also the
      setting of "auto_reconnect" variable to 0 is delayed and is
      done after "COM_QUIT" command.
            
      NOTE:- For reproducing this issue, "tcp_keepalive_time" has
      to be set to a smaller value. This value is set in the
      "/proc/sys/net/ipv4/tcp_keepalive_time" file in Unix
      systems. So we need root permission for changing it, which
      can't be done through mtr test. So submitting the patch
      without mtr test.
      a9b61b00
  21. 06 Nov, 2014 2 commits
    • Jon Olav Hauglid's avatar
      Bug#19974500: SERVER 5.5 / DEBUG DOESN\'T COMPILE WITH GCC 4.9.1 · 5a59bf7a
      Jon Olav Hauglid authored
      Fix broken gcc 4.9.1 debug build by removing end of line noise.
      
      In 5.6+ this issue was already fixed by:
      ------------------------------------------------------------
      revno: 3091
      committer: Davi Arnaut <davi.arnaut@oracle.com>
      branch nick: mysql-trunk
      timestamp: Mon 2011-05-16 11:30:54 -0300
      message:
        Fix warnings emitted by Clang.
      5a59bf7a
    • Kent Boortz's avatar
      Bug #18957951 RPMBUILD DEPENDENCY SCANNER ADDS DEPENDENCY ON NON-EXISTING PERL "HOSTNAMES" · bd7e5aba
      Kent Boortz authored
      When building RPMs and using the "rpmbuild" automatic scanning for
      Perl dependencies, it might interpret "use hostnames" in the
      "mysql_config.pl" script usage comment as a Perl "use" statement.
      And then makes the resulting RPMs depends on a non-existing module
      Perl "hostnames". The comment was changed to prevent this.
      bd7e5aba
  22. 04 Nov, 2014 2 commits
  23. 03 Nov, 2014 2 commits
  24. 30 Oct, 2014 1 commit
  25. 29 Oct, 2014 1 commit
    • Annamalai Gurusami's avatar
      Bug #19908343 SERVER CRASHES WHEN EXECUTING ALTER TABLE · 42742426
      Annamalai Gurusami authored
      Problem:
      
      In the function dict_foreign_remove_from_cache(), the rb tree was updated
      without actually verifying whether the given foreign key object is there in the
      rb tree or not.  There can be an existing foreign key object with the same id 
      in the rb tree, which must not be removed.  Such a scenario comes when an
      attempt is made to add a foreign key object with a duplicate identifier.
      
      Solution:
      
      When the foreign key object is removed from the dictionary cache, ensure
      that the foreign key object removed from the rbt is the correct one.
      
      rb#7168 approved by Jimmy and Marko.
      42742426
  26. 27 Oct, 2014 1 commit
    • Marko Makela's avatar
      Bug#19584379 Reporting corruption may corrupt the innodb data dictionary · 352b6bc9
      Marko Makela authored
      dict_set_corrupted(): Use the canonical way of searching for
      less-than-equal (PAGE_CUR_LE) and then checking low_match.
      
      The code that was introduced in MySQL 5.5.17 in
          Bug#11830883 SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES
      could position the cursor on the page supremum, and then attempt
      to overwrite non-existing 7th field of the 1-field supremum record.
      
      Approved by Jimmy Yang
      352b6bc9
  27. 23 Oct, 2014 1 commit
  28. 21 Oct, 2014 3 commits
  29. 20 Oct, 2014 1 commit
  30. 17 Oct, 2014 1 commit
    • Arun Kuruvila's avatar
      Bug #14486004 MYSQL_SETPERMISSION DOES NOT QUOTE USER NAMES · bb14cc03
      Arun Kuruvila authored
      Description: Certain operations using the client tool
      'mysql\_setpermisson' which uses username of the format 
      "xxx-yyy" results in a syntax error.
      
      Analysis: The user name variable ( $user ) was not quoted
      properly in the 'mysql\_setpermission' script. As a result,
      while granting user privileges for a user with username of
      the format 'xxx-yyy', results in a syntax error.
      
      Fix: The escape sequence has been applied for the user
      variable in the script file.
      
      Note: Test case is not added for this fix.
      'mysql\_setpermission' executable resides in different
      directories on pb2 machines and on local boxes. Hence the 
      test case cannot be made generic.
      bb14cc03
  31. 13 Oct, 2014 1 commit
    • Jon Olav Hauglid's avatar
      Bug#17633291: SET PROPER COMPILE OPTIONS FOR CLANG · 8b64f825
      Jon Olav Hauglid authored
      Bug#17959689: MAKE GCC AND CLANG GIVE CONSISTENT COMPILATION WARNINGS
      Bug#18313717: ENABLE -WERROR IN MAINTANER MODE WHEN COMPILING WITH CLANG
      Bug#18510941: REMOVE CMAKE WORKAROUNDS FOR OLDER VERSIONS OF OS X/XCODE
        
      Backport from mysql-5.6 to mysql-5.5
      8b64f825