1. 20 Sep, 2013 2 commits
  2. 19 Sep, 2013 1 commit
  3. 17 Sep, 2013 1 commit
  4. 12 Sep, 2013 4 commits
  5. 11 Sep, 2013 1 commit
    • Satya Bodapati's avatar
      Bug#16752251 - INNODB DOESN'T REDO-LOG INSERT BUFFER MERGE OPERATION IF · 59402fe0
      Satya Bodapati authored
      	       IT IS DONE IN-PLACE
      
      With change buffer enabled, InnoDB doesn't write a transaction log
      record when it merges a record from the insert buffer to an secondary
      index page if the insertion is performed as an update-in-place.
      
      Fixed by logging the 'update-in-place' operation on secondary index
      pages.
      
      Approved by Marko. rb#2429
      59402fe0
  6. 10 Sep, 2013 2 commits
    • mithun's avatar
      Bug #16978278 : BUFFER OVERFLOW WHEN PRINTING A LARGE 64-BIT INTEGER · 42501173
      mithun authored
                      WITH MY_B_VPRINTF()
      Issue         : In LP 64 machine max long value can be 20 digit
                      decimal value. But in my_b_vprintf() the intermediate
                      buffer storage used is 17 bytes length. This will lead to
                      buffer overflow.
      Solution      : Increased the buffer storage from 17 to 32 bytes.
                      code is backported from 5.6
      
      
      mysys/mf_iocache2.c:
        In function my_b_vprintf increased the size of local buff from 17 to
        32 bytes.
      42501173
    • Tor Didriksen's avatar
      Bug#16482467 ORDER BY IGNORED IN SOME SITUATIONS FOR UPDATE QUERY · b9ec1837
      Tor Didriksen authored
      For queries like
      update t1 set ... where <unique key> order by ... limit ...
      we need to handle the fact that unique keys allow NULL
      values, and hence can return more than one row.
      
      
      sql/opt_range.cc:
        When the unique key has multiple key parts,
        check each key_part for nullability, rather than the first key part.
        (s/key->part ==/key_tree->part ==/)
        
        Also: revert the if() test, for better readability.
      b9ec1837
  7. 11 Sep, 2013 1 commit
  8. 10 Sep, 2013 6 commits
  9. 09 Sep, 2013 6 commits
  10. 06 Sep, 2013 1 commit
  11. 05 Sep, 2013 2 commits
  12. 04 Sep, 2013 1 commit
    • Neeraj Bisht's avatar
      Bug#17222452 - SELECT COUNT(DISTINCT A,B) INCORRECTLY COUNTS ROWS · e203951c
      Neeraj Bisht authored
      	       CONTAINING NULL
      
      Problem:-
      In MySQL, We can obtain the number of distinct expression
      combinations that do not contain NULL by giving a list of 
      expressions in COUNT(DISTINCT).
      However rows with NULL values are
      incorrectly included in the count when loose index scan is 
      used.
      
      Analysis:-
      In case of loose index scan, we check whether the field is null or 
      not and increase the count in Item_sum_count::add().
      But there we are checking for the first field in COUNT(DISTINCT), 
      not for every field. This is causing an incorrect result.
      
      Solution:-
      Check all field in Item_sum_count::add(), whether there values 
      are null or not. Then only increment the count.
      ******
      Bug#17222452 - SELECT COUNT(DISTINCT A,B) INCORRECTLY COUNTS ROWS 
      	       CONTAINING NULL
      
      Problem:-
      In MySQL, We can obtain the number of distinct expression
      combinations that do not contain NULL by giving a list of 
      expressions in COUNT(DISTINCT).
      However rows with NULL values are
      incorrectly included in the count when loose index scan is 
      used.
      
      Analysis:-
      In case of loose index scan, we check whether the field is null or 
      not and increase the count in Item_sum_count::add().
      But there we are checking for the first field in COUNT(DISTINCT), 
      not for every field. This is causing an incorrect result.
      
      Solution:-
      Check all field in Item_sum_count::add(), whether there values 
      are null or not. Then only increment the count.
      e203951c
  13. 02 Sep, 2013 1 commit
    • Arun Kuruvila's avatar
      Bug #17168602 MYSQL_PLUGIN REMOVES NON-DIRECTORY TYPE FILES · a7526397
      Arun Kuruvila authored
                    SPECIFIED WITH THE BASEDIR OPTION
      
      Description: The mysql_plugin client attempts to remove any
      filename specified to the --basedir option. The problem is 
      that if the filename does not end with a slash, it will 
      attempt to unlink it, which succeeds for files, but not for 
      directories.
      
      Analysis: When we are starting mysql_plugin with basedir 
      option and if we are giving path of a file as basedir, it 
      deletes that file. It was because it uses a function 
      my_delete which unlinks the file path given.
      
      Fix:  As a fix we replace that line using another function 
      my_free, which will only free the  pointer which is having 
      that file path.
      a7526397
  14. 01 Sep, 2013 1 commit
  15. 30 Aug, 2013 5 commits
  16. 29 Aug, 2013 1 commit
  17. 28 Aug, 2013 3 commits
    • Raghav Kapoor's avatar
      BUG#17294150-POTENTIAL CRASH DUE TO BUFFER OVERRUN IN SSL · facdeb5f
      Raghav Kapoor authored
                   ERROR HANDLING CODE 
      
      BACKGROUND:
      There can be a potential crash due to buffer overrun in 
      SSL error handling code due to missing comma in
      ssl_error_string[] array in viosslfactories.c.
      
      ANALYSIS:
      Found by code Inspection.
      
      FIX:
      Added the missing comma in SSL error handling code
      in ssl_error_string[] array in viosslfactories.c.
      facdeb5f
    • Raghav Kapoor's avatar
      BUG#17294150-POTENTIAL CRASH DUE TO BUFFER OVERRUN IN SSL · 881e61db
      Raghav Kapoor authored
                   ERROR HANDLING CODE 
      
      BACKGROUND:
      There can be a potential crash due to buffer overrun in 
      SSL error handling code due to missing comma in
      ssl_error_string[] array in viosslfactories.c.
      
      ANALYSIS:
      Found by code Inspection.
      
      FIX:
      Added the missing comma in SSL error handling code
      in ssl_error_string[] array in viosslfactories.c.
      881e61db
    • Neeraj Bisht's avatar
      Bug#16346241 - SERVER CRASH IN ITEM_PARAM::QUERY_VAL_STR · 277697b8
      Neeraj Bisht authored
      Problem:-
      Second execution of prepared statement for query with 
      parameter in limit clause, causes an assert when using 
      connectors (e.g., Connector C).  
      
      
      Analysis:-
      In prepared statement, LIMIT parameters can be
      specified using '?' markers. Value for the parameter can
      be supplied while executing the prepared statement.
      
      Passing string, float or double values for LIMIT clause
      works well from command-line client. That's because, while 
      setting the LIMIT parameter value from a user-variable,
      the value is converted to integer value.
      
      However, when prepared statement is executed from other
      interfaces as J connectors, or C applications etc,
      the value for the parameters are sent to the server
      with execute command. Each item in command has value and
      the data TYPE. So, while setting parameter values
      from this log, value is set to all the parameters
      with the same data type as passed.
      Here, we have the logic to convert the value to change the 
      state and item_type if it is part of LIMIT parameter and 
      its item_type is not INT.
      But when we reset this parameter we save the item_type but change 
      state. So on second execution we have old item_type but our state 
      has been changed, which make us to use string type variable 
      in Item_param::query_str_val(). This cause an assert.
      
      Fix:
      Instead of checking the item_type of the parameter, check for 
      the state of the parameter. As state value are reset everytime
      we execute the statement.
      277697b8
  18. 27 Aug, 2013 1 commit