1. 30 Mar, 2007 3 commits
    • sergefp@mysql.com's avatar
      dd7e39f4
    • sergefp@mysql.com's avatar
      BUG#26624: high mem usage (crash) in range optimizer · dcb25513
      sergefp@mysql.com authored
      Pushbuild fixes: 
       - Make MAX_SEL_ARGS smaller (even 16K records_in_range() calls is 
         more than it makes sense to do in typical cases)
       - Don't call sel_arg->test_use_count() if we've already allocated 
         more than MAX_SEL_ARGs elements. The test will succeed but will take
         too much time for the test suite (and not provide much value).
      dcb25513
    • evgen@sunlight.local's avatar
      Bug#23233: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE in the · 7c42232d
      evgen@sunlight.local authored
      NO_AUTO_VALUE_ON_ZERO mode.
      
      In the NO_AUTO_VALUE_ON_ZERO mode the table->auto_increment_field_not_null
      variable is used to indicate that a non-NULL value was specified by the user
      for an auto_increment column. When an INSERT .. ON DUPLICATE updates the
      auto_increment field this variable is set to true and stays unchanged for the
      next insert operation. This makes the next inserted row sometimes wrongly have
      0 as the value of the auto_increment field.
      
      Now the fill_record() function resets the table->auto_increment_field_not_null
      variable before filling the record.
      The table->auto_increment_field_not_null variable is also reset by the
      open_table() function for a case if we missed some auto_increment_field_not_null
      handling bug.
      Now the table->auto_increment_field_not_null is reset at the end of the
      mysql_load() function.
      
      Reset the table->auto_increment_field_not_null variable after each
      write_row() call in the copy_data_between_tables() function.
      
      7c42232d
  2. 29 Mar, 2007 7 commits
  3. 28 Mar, 2007 6 commits
  4. 27 Mar, 2007 2 commits
    • igor@olga.mysql.com's avatar
      Fixed bug #27348. · adc07255
      igor@olga.mysql.com authored
      If a set function with a outer reference s(outer_ref) cannot be aggregated 
      the outer query against which the reference has been resolved then MySQL
      interpretes s(outer_ref) in the same way as it would interpret s(const).
      Hovever the standard requires throwing an error in this situation.
      Added some code to support this requirement in ansi mode.
      Corrected another minor bug in Item_sum::check_sum_func.
       
      adc07255
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #26815: · 4f2ec8f3
      gkodinov/kgeorge@magare.gmz authored
       When creating a temporary table the concise column type
       of a string expression is decided based on its length:
       - if its length is under 512 it is stored as either 
         varchar or char.
       - otherwise it is stored as a BLOB.
       
       There is a flag (convert_blob_length) to create_tmp_field 
       that, when >0 allows to force creation of a varchar if the
       max blob length is under convert_blob_length.
       However it must be verified that convert_blob_length 
       (settable through a SQL option in some cases) is 
       under the maximum that can be stored in a varchar column.
       While performing that check for expressions in 
       create_tmp_field_from_item the max length of the blob was
       used instead. This causes blob columns to be created in the
       heap temp table used by GROUP_CONCAT (where blobs must not
       be created in the temp table because of the constant 
       convert_blob_length that is passed to create_tmp_field() ).
       And since these blob columns are not expected in that place
       we get wrong results.
       Fixed by checking that the value of the flag variable is 
       in the limits that fit into VARCHAR instead of the max length
       of the blob column.
      4f2ec8f3
  5. 26 Mar, 2007 5 commits
  6. 23 Mar, 2007 1 commit
  7. 22 Mar, 2007 16 commits