1. 14 Jun, 2006 3 commits
  2. 13 Jun, 2006 1 commit
    • gkodinov@mysql.com's avatar
      Bug #20195: INSERT DELAYED with auto_increment is assigned wrong values · 8d94b8ca
      gkodinov@mysql.com authored
      The INSERT DELAYED should not maintain its own private auto-increment
      counter, because this is assuming that other threads cannot insert
      into the table while the INSERT DELAYED thread is inserting, which is
      a wrong assumption.
      
      So the start of processing of a batch of INSERT rows in the 
      INSERT DELAYED thread must be treated as a start of a new statement
      and cached next_insert_id must be cleared.
      8d94b8ca
  3. 11 Jun, 2006 1 commit
  4. 08 Jun, 2006 2 commits
    • gkodinov@mysql.com's avatar
      Merge mysql.com:/home/kgeorge/mysql/5.0/teamclean · c9bb9413
      gkodinov@mysql.com authored
      into  mysql.com:/home/kgeorge/mysql/5.0/B15355
      c9bb9413
    • gkodinov@mysql.com's avatar
      Bug #15355: Common natural join column not resolved in prepared statement nested · 395affb8
      gkodinov@mysql.com authored
        query
      Problem:
      There was a wrong context assigned to the columns that were added in insert_fields()
      when expanding a '*'. When this is done in a prepared statement it causes 
      fix_fields() to fail to find the table that these columns reference.
      Actually the right context is set in setup_natural_join_row_types() called at the 
      end of setup_tables(). However when executed in a context of a prepared statement
      setup_tables() resets the context, but setup_natural_join_row_types() was not
      setting it to the correct value assuming it has already done so.
      
      Solution:
      The top-most, left-most NATURAL/USING join must be set as a 
      first_name_resolution_table in context even when operating on prepared statements.
      395affb8
  5. 03 Jun, 2006 1 commit
  6. 02 Jun, 2006 6 commits
  7. 30 May, 2006 3 commits
  8. 29 May, 2006 16 commits
  9. 28 May, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19225: unchecked error results in server crash · 1f30bf5a
      evgen@moonbone.local authored
      In multi-table delete a table for delete can't be used for selecting in
      subselects. Appropriate error was raised but wasn't checked which leads to a
      crash at the execution phase.
      
      The mysql_execute_command() now checks for errors before executing select
      for multi-delete.
      1f30bf5a
  10. 26 May, 2006 6 commits