1. 29 Jun, 2006 36 commits
  2. 28 Jun, 2006 4 commits
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-5.0 · 48d1dc74
      unknown authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug10946
      
      
      mysql-test/r/trigger.result:
        Auto merged
      mysql-test/t/trigger.test:
        Auto merged
      sql/sql_trigger.cc:
        Auto merged
      48d1dc74
    • unknown's avatar
      Bug#10946: Confusing error messeges in the case of duplicate trigger definition · 837c9719
      unknown authored
      It was hard to distinguish case, when one was unable to create trigger
      on the table because trigger with same action time and event already
      existed for this table, from the case, when one tried to create trigger
      with name which was already occupied by some other trigger, since in
      both these cases we emitted ER_TRG_ALREADY_EXISTS error and message.
      Now we emit ER_NOT_SUPPORTED_YET error with appropriate additional
      message in the first case. There is no sense in introducing separate
      error for this situation since we plan to get rid of this limitation
      eventually.
      
      
      mysql-test/r/trigger.result:
        Update result for new error message.
      mysql-test/t/trigger.test:
        Update test for new error code.
      sql/sql_trigger.cc:
        If there is already a trigger with the same activation time, report an
        "Unsupported yet" error.
      837c9719
    • unknown's avatar
      A fix for Bug#19022 "Memory bug when switching db during trigger execution". · 88843709
      unknown authored
      No test case as the bug is in an existing test case (rpl_trigger.test
      when it is run under valgrind).
      The warning was caused by memory corruption in replication slave: thd->db
      was pointing at a stack address that was previously used by 
      sp_head::execute()::old_db. This happened because mysql_change_db
      behaved differently in replication slave and did not make a copy of the 
      argument to assign to thd->db. 
      The solution is to always free the old value of thd->db and allocate a new
      copy, regardless whether we're running in a replication slave or not.
      
      
      sql/log_event.cc:
        Move rewrite_db to log_event.cc, the only place where it is used.
      sql/slave.cc:
        Move rewrite_db to log_event.cc
      sql/slave.h:
        Remove an unneeded declaration.
      sql/sql_class.h:
        Fix set_db to always free the old db, even if the argument is NULL.
        Add a comment.
      sql/sql_db.cc:
        Always make a deep copy of the argument in mysql_change_db, even 
        if running in a replication slave. This is necessary because 
        sp_use_new_db (stored procedures) assumes that mysql_change_db always makes
        a deep copy of the argument, and thus passes a pointer to stack into it.
        This assumption was true for all cases except the replication slave thread.
      88843709
    • unknown's avatar
      BUG #19773 · 9016a6be
      unknown authored
      Pushbuild fixes to result file, test, and header file for federated.
      
      
      mysql-test/r/federated.result:
        BUG #19773
        
        Pushbuild fixes - result file had hard-coded port
      mysql-test/t/federated.test:
        BUG #19773
        
        Pushbuild fixes Test was missing --replace_result
      sql/ha_federated.h:
        BUG #19773
        
        HPUX and Windows failed with variable named row and *row in method declaration
      9016a6be