1. 17 Jul, 2014 1 commit
    • Praveenkumar Hulakund's avatar
      Bug#14757009: WHEN THE GENERAL_LOG IS A SOCKET AND THE READER · cd4fb2ae
      Praveenkumar Hulakund authored
                    GOES AWAY, MYSQL QUITS WORKING.
      
      Analysis:
      -----------------
      Issue in this bug and in bug 11907705 is, the socket file or
      fifo file is set for general log at command line while starting
      the server. But currently, only regular file can be set for the 
      general log. Instead of reporting any error, the provided files
      are opened for writing and continued. Because of this issues
      mentioned in the bug reports are seen.
      
      As mentioned, only when any non-regular file is set for general
      log at command line while starting the server, these issues are
      seen. If general log file is set to non-regular file from CLI
      using system variable general_log_file then error is reported.
      
      These issues can also be faced with slow query log file, if it is
      set to non-regular file.
      
      Fix:
      -----------------
      Currently while starting the server if we fail to open log file
      then we report an error, disable logging to file and continue.
      To fix issue reported code is modified to check whether file
      is regular file or not before opening it. If file is not a 
      regular file then error is logged to error log and logging to 
      file is disabled.
      cd4fb2ae
  2. 09 Jul, 2014 3 commits
  3. 08 Jul, 2014 3 commits
  4. 07 Jul, 2014 1 commit
  5. 03 Jul, 2014 3 commits
    • Ashish Agarwal's avatar
      WL#7219: Implement audit filter · 61a79e5e
      Ashish Agarwal authored
      61a79e5e
    • Chaithra Reddy's avatar
      Bug#18469276: MOD FOR SMALL DECIMALS FAILS · 57fc0240
      Chaithra Reddy authored
            
      Problem:
      If leading zeroes of fractional part of a decimal
      number exceeds 45, mod operation on the same fails.
            
      Analysis:
      Currently there is a miscalcultion of fractional
      part for very small decimals in do_div_mod.
            
      For ex:
      For 0.000(45 times).....3
      length of the integer part becomes -5 (for a length of one,
      buffer can hold 9 digits. Since number of zeroes are 45, integer
      part becomes 5) and it is negative because of the leading
      zeroes present in the fractional part.
      Fractional part is the number of digits present after the
      point which is 46 and therefore rounded off to the nearest 9
      multiple which is 54. So the length of the resulting fractional
      part becomes 6.
            
      Because of this, the combined length of integer part and fractional
      part exceeds the max length allocated which is 9 and thereby failing.
            
      Solution:
      In case of negative integer value, it indicates there are
      leading zeroes in fractional part. As a result stop1 pointer 
      should be set not just based on frac0 but also intg0. This is
      because the detination buffer will be filled with 0's for the length
      of intg0.
      57fc0240
    • Annamalai Gurusami's avatar
      Bug #19140907 DUPLICATES IN UNIQUE SECONDARY INDEX BECAUSE OF FIX OF BUG#68021 · 76e690fb
      Annamalai Gurusami authored
      Problem:
      
      When a unique secondary index is scanned for duplicate checking, gap locks
      were not taken if the transaction had isolation level <= READ COMMITTED. 
      This change was done while fixing Bug #16133801 UNEXPLAINABLE INNODB UNIQUE
      INDEX LOCKS ON DELETE + INSERT WITH SAME VALUES (rb#2035). Because of this
      the duplicate check logic failed, and resulted in duplicate values in unique
      secondary index.
      
      Solution:
      
      When a unique secondary index is scanned for duplicate checking, gap locks
      must be taken irrespective of the transaction isolation level.  This is
      achieved by reverting rb#2035.
      
      rb#5910 approved by Jimmy
      76e690fb
  6. 02 Jul, 2014 3 commits
    • Arun Kuruvila's avatar
      Bug#17873011 NO DEPRECATION WARNING FOR THREAD_CONCURRENCY · cf50d1e6
      Arun Kuruvila authored
      Description:
      THREAD_CONCURRENCY is deprecated and there is no 
      deprecation warning message while setting this variable
      while starting the server.
      
      Analysis:
      This variable is specific to Solaris 8 and earlier systems
      and is ignored on all other platforms. But since many 
      customers, who uses other than Solaris, still has this 
      variable in their configuration file, it is important to
      have a deprecation warning.
      
      Fix:
      THREAD_CONCURRENCY deprecation warning message is added.
      cf50d1e6
    • Marcin Babij's avatar
      BUG#18779944: MYSQLDUMP BUFFER OVERFLOW · 43268d20
      Marcin Babij authored
      Mysqldump overflows stack buffer when copying table name from commandline arguments resulting in stack corruption and ability to execute arbitrary code.
      
      Fix: Check length of all positional arguments passed to mysqldump is smaller than NAME_LEN.
      Note: Mysqldump heavily depends on that database objects (databases, tablespaces, tables, etc) are limited to small size (now it is 64).
      43268d20
    • Bjorn Munch's avatar
  7. 01 Jul, 2014 2 commits
  8. 30 Jun, 2014 2 commits
  9. 27 Jun, 2014 5 commits
  10. 26 Jun, 2014 3 commits
    • Luis Soares's avatar
      BUG#13874553: rpl.rpl_stop_slave fails sporadically on pb2 · 18fa87d4
      Luis Soares authored
      The test case makes use of the fine DEBUG_SYNC facility. Furthermore,
      since it needs synchronization on internal threads (dump and SQL
      threads) the server code has DEBUG_SYNC commands internally deployed
      and activated through the DBUG_EXECUTE_IF macro. The internal
      DBUG_SYNC commands are then controlled from the test case through the
      DEBUG variable.
      
      There were three problems around the DEBUG + DEBUG_SYNC facility
      usage:
      
      1. When signaling the SQL thread to continue, the test would reset
         immediately the DEBUG_SYNC variable. This could mean that the SQL
         thread might loose the signal and continue to wait forever;
      
      2. A similar scenario was happening with the dump thread on the
         master. This thread was instructed to wait, and later it would be
         signaled to continue, but immediately after the DEBUG_SYNC would be
         reset. This could lead to the dump thread missing the signal and
         wait forever;
      
      3. The test was not cleaning itself up with respect to the
         instrumentation of the dump thread. This would leave the
         conditional execution of an internal DEBUG_SYNC command active
         (through the usage of DBUG_EXECUTE_IF). 
      
      We fix #1 and #2 by waiting for the threads to receive the signal and
      only then issue the reset. We fix #3 by reseting the DEBUG variable,
      thus deactivating the dump thread internal DEBUG_SYNC command.
      18fa87d4
    • Balasubramanian Kandasamy's avatar
    • Arun Kuruvila's avatar
      Bug#18463911 : SERVER CRASHES ON CREATING A TEMP TABLE WITH · dd31a2c2
      Arun Kuruvila authored
                     CERTAIN MAX_HEAP_TABLE_SIZE VALUES
      
      Followup patch to fix failure on Window machine.
      dd31a2c2
  11. 25 Jun, 2014 6 commits
    • Raghav Kapoor's avatar
      BUG#17665767 - FAILING ASSERTION: PRIMARY_KEY_NO == -1 || PRIMARY_KEY_NO == 0 · f4992925
      Raghav Kapoor authored
      BACKGROUND:
      This bug is a followup on Bug#16368875.
      The assertion failure happens because in SQL layer the key
      does not get promoted to PRIMARY KEY but InnoDB takes it
      as PRIMARY KEY.
      
      ANALYSIS:
      Here we are trying to create an index on POINT (GEOMETRY)
      data type which is a type of BLOB (since GEOMETRY is a
      subclass of BLOB).
      In general, we can't create an index over GEOMETRY family
      type field unless we specify the length of the
      keypart (similar to BLOB fields).
      Only exception is the POINT field type. The POINT column
      max size is 25. The problem is that the field is not treated
      as PRIMARY KEY when we create a index on POINT column using
      its max column size as key part prefix. The fix would allow
      index on POINT column to be treated as PRIMARY KEY.
      
      FIX:
      Patch for Bug#16368875 is extended to take into account
      GEOMETRY datatype, POINT in particular to consider it
      as PRIMARY KEY in SQL layer.
      f4992925
    • Nisha Gopalakrishnan's avatar
      BUG#18405221: SHOW CREATE VIEW OUTPUT INCORRECT · b278384f
      Nisha Gopalakrishnan authored
      Fix:
      ---
      The issue reported is same as the BUG#14117018.
      Hence backporting the patch from mysql-trunk
      to mysql-5.5 and mysql-5.6
      b278384f
    • Terje Rosten's avatar
      Bug#16395459 TEST AND RESULT FILES WITH EXECUTE BIT · 5c4937c1
      Terje Rosten authored
      Bug#16415173 CRLF INSTEAD OF LF IN SQL-BENCH SCRIPTS
            
      Correct perms and converts from Windows style to UNIX style line endings on some files.
      Fix perms on installed ini files.
      
      (MySQL 5.5 version)
      5c4937c1
    • Balasubramanian Kandasamy's avatar
    • Arun Kuruvila's avatar
      Bug #18463911 : SERVER CRASHES ON CREATING A TEMP TABLE · 774095a5
      Arun Kuruvila authored
                      WITH CERTAIN MAX_HEAP_TABLE_SIZE VALUES
      
      Description:
      When the  system variable 'max_heap_table_size'
      is set to 20GB, the server crashes on creation of a
      temporary tables or tables using MEMORY storage engine.
      
      Analysis:
      The variable 'max_record' determines the amount heap
      allocated for the records of the table. This value
      is determined using the 'max_heap_table_size' variable.
      'records_in_block' in turn uses the max_records to
      determine the number of records per block.
      
      When the 'max_heap_table_size' is set to 20GB, then
      the 'records_in_block' is calculated to a value of
      2^28.
      
      The size of the block determined by multiplying the
      'records_in_block' and 'recbuffer' results in overflow
      and hence the value becomes zero. As a result, zero bytes
      of the heap is allocated for the table. This will
      result in a server crash when the table is accessed.
      
      Fix:
      The variables 'records_in_block' and 'recbuffer' are
      typecasted to 'unsigned long' while calculating the
      size of the block.
      774095a5
    • Gopal Shankar's avatar
      Bug#18776592 INNODB: FAILING ASSERTION: PRIMARY_KEY_NO == -1 || · e107c24f
      Gopal Shankar authored
                                              PRIMARY_KEY_NO == 0 
      
      This bug is a backport of the following revision of 5.6 source tree:
      # committer: Gopal Shankar <gopal.shankar@oracle.com>
      # branch nick: priKey56
      # timestamp: Wed 2013-05-29 11:11:46 +0530
      # message:
      #   Bug#16368875 INNODB: FAILING ASSERTION:
      e107c24f
  12. 24 Jun, 2014 2 commits
    • Jon Olav Hauglid's avatar
      Bug#19001781: ADD SUPPORT FOR CMAKE 3 · 68841679
      Jon Olav Hauglid authored
      Set CMP0026 and CMP0045 policies when using CMake 
      version 3 or higher to restore old CMake behavior.
      68841679
    • Nisha Gopalakrishnan's avatar
      BUG#18618561: FAILED ALTER TABLE ENGINE CHANGE WITH PARTITIONS · 0e947e88
      Nisha Gopalakrishnan authored
                    CORRUPTS FRM
      
      Analysis:
      ---------
      ALTER TABLE on a partitioned table resulted in the wrong
      engine being written into the table's FRM file and displayed
      in SHOW CREATE TABLE.
      
      The prep_alter_part_table() modifies the partition_info object
      for TABLE instance representing the old version of table.
      If the ALTER TABLE ENGINE statement fails, the partition_info
      object for the TABLE contains the altered storage engine name.
      The SHOW CREATE TABLE uses the TABLE object to display the table
      information, hence displays incorrect storage engine for the table.
      Also a subsequent successful ALTER TABLE operation will write the
      incorrect engine information into the FRM file.
      
      Fix:
      ---
      A copy of the partition_info object is created before modification so
      that any changes would not cause the the original partition_info object
      to be modified if the ALTER TABLE fails.(Backported part of the code
      provided as fix for bug#14156617 in mysql-5.6.6).
      0e947e88
  13. 23 Jun, 2014 2 commits
  14. 19 Jun, 2014 1 commit
  15. 18 Jun, 2014 1 commit
    • Namit Sharma's avatar
      Bug#18949527 SUITE/BINLOG/T/BINLOG_KILLED.TEST FORGETS TO · 6907449d
      Namit Sharma authored
                   DISCONNECT CON1 AND CON2
        
      Problem:
      The test suite/binlog/t/binlog_killed.test makes the connections
      con1 and con2 but forgets to disconnect them + wait till that
      operation is finished at test end.
      This mistake has the potential to harm subsequent tests in
      case these tests depend on the content of the processlist.
       
      Solution:
      Added disconnect + wait_until_disconnected.inc 
      within the test cleanup.
      6907449d
  16. 17 Jun, 2014 2 commits