1. 28 Jun, 2006 5 commits
    • kroki@mysql.com's avatar
      Merge mysql.com:/home/tomash/src/mysql_ab/mysql-5.0 · 9c3805c9
      kroki@mysql.com authored
      into  mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug10946
      9c3805c9
    • kroki@mysql.com's avatar
      Bug#10946: Confusing error messeges in the case of duplicate trigger definition · 3e2e20ec
      kroki@mysql.com 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.
      3e2e20ec
    • 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
    • jimw@mysql.com's avatar
      Merge bk-internal:/home/bk/mysql-5.0-runtime · 9bcb24b6
      jimw@mysql.com authored
      into  mysql.com:/home/jimw/my/mysql-5.0-18005
      9bcb24b6
    • jimw@mysql.com's avatar
      Bug #18005: Creating a trigger on mysql.event leads to server crash on scheduler startup · 5d2c0de5
      jimw@mysql.com authored
      Bug #18361: Triggers on mysql.user table cause server crash
      
       Because they do not work, we do not allow creating triggers on tables
       within the 'mysql' schema.
      
       (They may be made to work and re-enabled at some later date, but not
       in 5.0 or 5.1.)
      5d2c0de5
  2. 27 Jun, 2006 5 commits
  3. 26 Jun, 2006 14 commits
    • konstantin@mysql.com's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 5576ef27
      konstantin@mysql.com authored
      into  mysql.com:/opt/local/work/mysql-5.0-17199
      5576ef27
    • kent@mysql.com's avatar
      Merge kboortz@bk-internal.mysql.com:/home/bk/mysql-5.0 · ca3e020b
      kent@mysql.com authored
      into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new
      ca3e020b
    • kent@mysql.com's avatar
      Merge mysql.com:/Users/kent/mysql/bk/mysql-4.1-new · b1d3bd5a
      kent@mysql.com authored
      into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new
      b1d3bd5a
    • kent@mysql.com's avatar
      Merge mysql.com:/Users/kent/mysql/bk/mysql-4.0 · 748b287c
      kent@mysql.com authored
      into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new
      748b287c
    • kent@mysql.com's avatar
      make_sharedlib_distribution.sh: · c36dd286
      kent@mysql.com authored
        For compatibility, don't use {..,..} in pattern matching
      make_binary_distribution.sh:
        Added .dylib and .sl as shared library extensions
      c36dd286
    • konstantin@mysql.com's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 4d25d215
      konstantin@mysql.com authored
      into  mysql.com:/opt/local/work/mysql-5.0-17199
      4d25d215
    • konstantin@mysql.com's avatar
      A fix and a test case for · 117b76a5
      konstantin@mysql.com authored
       Bug#19022 "Memory bug when switching db during trigger execution"
       Bug#17199 "Problem when view calls function from another database."
       Bug#18444 "Fully qualified stored function names don't work correctly in
                  SELECT statements"
      
       Documentation note: this patch introduces a change in behaviour of prepared
       statements.
      
       This patch adds a few new invariants with regard to how THD::db should
       be used. These invariants should be preserved in future:
      
        - one should never refer to THD::db by pointer and always make a deep copy
          (strmake, strdup)
        - one should never compare two databases by pointer, but use strncmp or
          my_strncasecmp
        - TABLE_LIST object table->db should be always initialized in the parser or
          by creator of the object.
      
          For prepared statements it means that if the current database is changed
          after a statement is prepared, the database that was current at prepare
          remains active. This also means that you can not prepare a statement that
          implicitly refers to the current database if the latter is not set.
          This is not documented, and therefore needs documentation. This is NOT a
          change in behavior for almost all SQL statements except:
           - ALTER TABLE t1 RENAME t2 
           - OPTIMIZE TABLE t1
           - ANALYZE TABLE t1
           - TRUNCATE TABLE t1 --
           until this patch t1 or t2 could be evaluated at the first execution of
           prepared statement. 
      
           CURRENT_DATABASE() still works OK and is evaluated at every execution
           of prepared statement.
      
           Note, that in stored routines this is not an issue as the default
           database is the database of the stored procedure and "use" statement
           is prohibited in stored routines.
      
        This patch makes obsolete the use of check_db_used (it was never used in the
        old code too) and all other places that check for table->db and assign it
        from THD::db if it's NULL, except the parser.
      
       How this patch was created: THD::{db,db_length} were replaced with a
       LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were
       manually checked and:
        - if the place uses thd->db by pointer, it was fixed to make a deep copy
        - if a place compared two db pointers, it was fixed to compare them by value
          (via strcmp/my_strcasecmp, whatever was approproate)
       Then this intermediate patch was used to write a smaller patch that does the
       same thing but without a rename.
      
       TODO in 5.1:
         - remove check_db_used
         - deploy THD::set_db in mysql_change_db
      
       See also comments to individual files.
      117b76a5
    • ingo@mysql.com's avatar
      Merge istruewing@bk-internal.mysql.com:/home/bk/mysql-5.0 · 50477229
      ingo@mysql.com authored
      into  mysql.com:/nfstmp1/ingo/autopush-75/mysql-5.0
      50477229
    • anozdrin@mysql.com's avatar
      Merge mysql.com:/home/alik/MySQL/devel/5.0-tree · 8f4582db
      anozdrin@mysql.com authored
      into  mysql.com:/home/alik/MySQL/devel/5.0-rt
      8f4582db
    • ingo@mysql.com's avatar
      Merge istruewing@bk-internal.mysql.com:/home/bk/mysql-5.0 · 0acdd0f7
      ingo@mysql.com authored
      into  mysql.com:/home/mydev/mysql-5.0-bug16986-main
      0acdd0f7
    • ingo@mysql.com's avatar
      Merge mysql.com:/home/mydev/mysql-5.0--main · d011ac72
      ingo@mysql.com authored
      into  mysql.com:/home/mydev/mysql-5.0-bug16986-main
      d011ac72
    • ingo@mysql.com's avatar
      Bug#16986 - Deadlock condition with MyISAM tables · d27a15a8
      ingo@mysql.com authored
      Addendum fixes after changing the condition variable
      for the global read lock.
      
      The stress test suite revealed some deadlocks. Some were
      related to the new condition variable (COND_global_read_lock)
      and some were general problems with the global read lock.
      
      It is now necessary to signal COND_global_read_lock whenever 
      COND_refresh is signalled.
      
      We need to wait for the release of a global read lock if one 
      is set before every operation that requires a write lock.
      But we must not wait if we have locked tables by LOCK TABLES.
      After setting a global read lock a thread waits until all
      write locks are released.
      d27a15a8
    • tnurnberg@mysql.com's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-maint · d5ff4f68
      tnurnberg@mysql.com authored
      into  mysql.com:/home/tnurnberg/mysql-5.0-maint-18462
      d5ff4f68
    • elliot@mysql.com's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0 · 374495ff
      elliot@mysql.com authored
      into  mysql.com:/data0/bk/mysql-5.0-maint
      374495ff
  4. 24 Jun, 2006 2 commits
  5. 23 Jun, 2006 9 commits
  6. 22 Jun, 2006 5 commits