1. 17 Nov, 2006 1 commit
  2. 16 Nov, 2006 4 commits
  3. 13 Nov, 2006 3 commits
    • malff/marcsql@weblab.(none)'s avatar
      Bug#23703 (DROP TRIGGER needs an IF EXISTS) · 429b0e6c
      malff/marcsql@weblab.(none) authored
      This change set implements the DROP TRIGGER IF EXISTS functionality.
      
      This fix is considered a bug and not a feature, because without it,
      there is no known method to write a database creation script that can create
      a trigger without failing, when executed on a database that may or may not
      contain already a trigger of the same name.
      
      Implementing this functionality closes an orthogonality gap between triggers
      and stored procedures / stored functions (which do support the DROP IF
      EXISTS syntax).
      
      In sql_trigger.cc, in mysql_create_or_drop_trigger,
      the code has been reordered to:
      - perform the tests that do not depend on the file system (access()),
      - get the locks (wait_if_global_read_lock, LOCK_open)
      - call access()
      - perform the operation
      - write to the binlog
      - unlock (LOCK_open, start_waiting_global_read_lock)
      
      This is to ensure that all the code that depends on the presence of the
      trigger file is executed in the same critical section,
      and prevents race conditions similar to the case fixed by Bug 14262 :
      
      - thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure
      - thread 2 executes CREATE TRIGGER
      - thread 2 logs CREATE TRIGGER
      - thread 1 logs DROP TRIGGER IF EXISTS
      
      The patch itself is based on code contributed by the MySQL community,
      under the terms of the Contributor License Agreement (See Bug 18161).
      429b0e6c
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 6fd6e099
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg23651
      6fd6e099
    • dlenev@mockturtle.local's avatar
      Fix for bug bug#23651 "Server crashes when trigger which uses · dd1a4f57
      dlenev@mockturtle.local authored
      stored function invoked from different connections".
      
      Invocation of trigger which was using stored function from different
      connections caused server crashes (for non-debug server this happened
      in highly concurrent environment, but debug server failed on assertion
      in relatively simple scenario).
      
      Item_func_sp was not safe to use in triggers (in other words for
      re-execution from different threads) as artificial TABLE object
      pointed by Item_func_sp::dummy_table referenced incorrect THD
      object. To fix the problem we force re-initialization of this
      object for each re-execution of statement.
      dd1a4f57
  4. 12 Nov, 2006 1 commit
  5. 11 Nov, 2006 3 commits
  6. 10 Nov, 2006 15 commits
  7. 09 Nov, 2006 4 commits
  8. 08 Nov, 2006 9 commits