1. 06 Jul, 2006 1 commit
    • unknown's avatar
      Bug #20569 Garbage in DECIMAL results from some mathematical functions · fb917563
      unknown authored
        Adding decimal "digits" in multiplication resulted in signed overflow and
      producing wrong results.
      
        Fixed by using large enough buffers and intermediary result types :
      dec2 (currently longlong) to hold result of adding decimal "digits" 
      (currently int32). 
      
      
      mysql-test/r/select.result:
        Bug #20569 Garbage in DECIMAL results from some mathematical functions
          * test suite for the bug
      mysql-test/t/select.test:
        Bug #20569 Garbage in DECIMAL results from some mathematical functions
          * test suite for the bug
      strings/decimal.c:
        Bug #20569 Garbage in DECIMAL results from some mathematical functions
          * fixed the overflow in adding decimal "digits"
      fb917563
  2. 29 Jun, 2006 36 commits
  3. 28 Jun, 2006 3 commits
    • unknown's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-5.0 · 6fa9d07f
      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
      6fa9d07f
    • unknown's avatar
      Bug#10946: Confusing error messeges in the case of duplicate trigger definition · 95552a89
      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.
      95552a89
    • unknown's avatar
      A fix for Bug#19022 "Memory bug when switching db during trigger execution". · 17f77591
      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.
      17f77591