1. 12 Sep, 2013 2 commits
  2. 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
  3. 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
  4. 11 Sep, 2013 1 commit
  5. 10 Sep, 2013 6 commits
  6. 09 Sep, 2013 4 commits
  7. 06 Sep, 2013 1 commit
  8. 05 Sep, 2013 2 commits
  9. 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
  10. 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
  11. 01 Sep, 2013 1 commit
  12. 30 Aug, 2013 3 commits
  13. 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
  14. 27 Aug, 2013 1 commit
  15. 26 Aug, 2013 3 commits
    • Hery Ramilison's avatar
      Empty version change upmerge · 9e0cd2df
      Hery Ramilison authored
      9e0cd2df
    • unknown's avatar
      Raise version number after cloning 5.1.72 · b3f8de5b
      unknown authored
      b3f8de5b
    • Dmitry Lenev's avatar
      Fix for bug #17356954 "CANNOT USE SAVEPOINTS AFTER ER_LOCK_DEADLOCK OR · fb5d9a82
      Dmitry Lenev authored
      ER_LOCK_WAIT_TIMEOUT".
      
      The problem was that after changes caused by fix bug 14188793 "DEADLOCK
      CAUSED BY ALTER TABLE DOEN'T CLEAR STATUS OF ROLLBACKED TRANSACTION"/
      bug 17054007 "TRANSACTION IS NOT FULLY ROLLED BACK IN CASE OF INNODB
      DEADLOCK implicit rollback of transaction which occurred on ER_LOCK_DEADLOCK
      (and ER_LOCK_WAIT_TIMEOUT if innodb_rollback_on_timeout option was set)
      didn't start new transaction in @@autocommit=1 mode.
      
      Such behavior although consistent with behavior of explicit ROLLBACK has
      broken expectations of users and backward compatibility assumptions.
      
      This patch fixes problem by reverting to starting new transaction
      in 5.5/5.6.
      
      The plan is to keep new behavior in trunk so the code change from this
      patch is to be null-merged there.
      fb5d9a82
  16. 23 Aug, 2013 8 commits
    • Praveenkumar Hulakund's avatar
      Bug#11765252 - READ OF FREED MEMORY WHEN "USE DB" AND · 72ff5686
      Praveenkumar Hulakund authored
                     "SHOW PROCESSLIST"
      
      Follow up path, addressing pb2 test failure.
      72ff5686
    • Praveenkumar Hulakund's avatar
    • unknown's avatar
      No commit message · 7ab5bcc1
      unknown authored
      No commit message
      7ab5bcc1
    • Neeraj Bisht's avatar
      Bug#17029399 - CRASH IN ITEM_REF::FIX_FIELDS WITH TRIGGER ERRORS · 6773c60f
      Neeraj Bisht authored
      Problem:-
      In a Procedure, when we are comparing value of select query 
      with IN clause and they both have different collation, cause 
      error on first time execution and assert second time.
      procedure will have query like
      set @x = ((select a from t1) in (select d from t2));<---proc1
                    sel1                   sel2
      
      Analysis:-
      When we execute this proc1(first time)
      While resolving the fields of user variable, we will call 
      Item_in_subselect::fix_fields while will resolve sel2. There 
      in Item_in_subselect::select_transformer, we evaluate the 
      left expression(sel1) and store it in Item_cache_* object 
      (to avoid re-evaluating it many times during subquery execution) 
      by making Item_in_optimizer class.
      While evaluating left expression we will prepare sel1.
      After that, we will put a new condition in sel2  
      in Item_in_subselect::select_transformer() which will compare 
      t2.d and sel1(which is cached in Item_in_optimizer).
      
      Later while checking the collation in agg_item_collations() 
      we get error and we cleanup the item. While cleaning up we cleaned 
      the cached value in Item_in_optimizer object.
      
      When we execute the procedure second time, we have condition for 
      sel2 and while setup_cond(), we can't able to find reference item 
      as it is cleanup while item cleanup.So it assert.
      
      
      Solution:-
      We should not cleanup the cached value for Item_in_optimizer object, 
      if we have put the condition to subselect.
      
      6773c60f
    • Neeraj Bisht's avatar
      Bug#17029399 - CRASH IN ITEM_REF::FIX_FIELDS WITH TRIGGER ERRORS · 356b6414
      Neeraj Bisht authored
      Problem:-
      In a Procedure, when we are comparing value of select query 
      with IN clause and they both have different collation, cause 
      error on first time execution and assert second time.
      procedure will have query like
      set @x = ((select a from t1) in (select d from t2));<---proc1
                    sel1                   sel2
      
      Analysis:-
      When we execute this proc1(first time)
      While resolving the fields of user variable, we will call 
      Item_in_subselect::fix_fields while will resolve sel2. There 
      in Item_in_subselect::select_transformer, we evaluate the 
      left expression(sel1) and store it in Item_cache_* object 
      (to avoid re-evaluating it many times during subquery execution) 
      by making Item_in_optimizer class.
      While evaluating left expression we will prepare sel1.
      After that, we will put a new condition in sel2  
      in Item_in_subselect::select_transformer() which will compare 
      t2.d and sel1(which is cached in Item_in_optimizer).
      
      Later while checking the collation in agg_item_collations() 
      we get error and we cleanup the item. While cleaning up we cleaned 
      the cached value in Item_in_optimizer object.
      
      When we execute the procedure second time, we have condition for 
      sel2 and while setup_cond(), we can't able to find reference item 
      as it is cleanup while item cleanup.So it assert.
      
      
      Solution:-
      We should not cleanup the cached value for Item_in_optimizer object, 
      if we have put the condition to subselect.
      
      
      356b6414
    • unknown's avatar
      No commit message · 5d75a4e6
      unknown authored
      No commit message
      5d75a4e6
    • unknown's avatar
      No commit message · d6825f49
      unknown authored
      No commit message
      d6825f49
    • Ashish Agarwal's avatar
      WL#7076: Backporting wl6715 to support both formats · 292aa926
      Ashish Agarwal authored
               in 5.5, 5.6, 5.7.
      292aa926