1. 22 Jul, 2006 1 commit
  2. 21 Jul, 2006 1 commit
  3. 19 Jul, 2006 2 commits
  4. 17 Jul, 2006 1 commit
  5. 14 Jul, 2006 1 commit
    • tnurnberg@mysql.com/salvation.intern.azundris.com's avatar
      Bug#21014: Segmentation fault of mysqldump on view · 00ec3973
      mysqldump did not select the correct database before trying to dump
      views from it. this resulted in an empty result set, which in turn
      startled mysql-dump into a core-dump.  this only happened for views,
      not for tables, and was only visible with multiple databases that
      weren't by sheer luck in the order mysqldump required, anyway. this
      fixes by selecting the correct database before dumping views; it also
      catches the empty set-condition if it should occur for other reasons.
      00ec3973
  6. 10 Jul, 2006 4 commits
  7. 04 Jul, 2006 3 commits
  8. 03 Jul, 2006 5 commits
  9. 01 Jul, 2006 2 commits
  10. 30 Jun, 2006 6 commits
  11. 29 Jun, 2006 13 commits
  12. 28 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix for Bug#19022 "Memory bug when switching db during trigger execution". · 55d148c5
      konstantin@mysql.com 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.
      55d148c5