An error occurred fetching the project authors.
  1. 03 Jun, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #26162: Trigger DML ignores low_priority_updates setting · 9a1d8adc
      gkodinov/kgeorge@macbook.gmz authored
        
      The value of "low-priority-updates" option and the LOW PRIORITY
      prefix was taken into account at parse time.
      This caused triggers (among others) to ignore this flag (if
      supplied for the DML statement).
      Moved reading of the LOW_PRIORITY flag at run time.
      Fixed an incosistency when handling
      SET GLOBAL LOW_PRIORITY_UPDATES : now it is in effect for
      delayed INSERTs.
      Tested by checking the effect of LOW_PRIORITY flag via a 
      trigger.
      9a1d8adc
  2. 11 May, 2007 1 commit
    • dlenev@mockturtle.local's avatar
      Fix for: · 8b93e52e
      dlenev@mockturtle.local authored
        Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT
                    with locked tables"
        Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers"
        Bug #24738 "CREATE TABLE ... SELECT is not isolated properly"
        Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when
                    temporary table exists"
       
      Deadlock occured when one tried to execute CREATE TABLE IF NOT
      EXISTS ... SELECT statement under LOCK TABLES which held
      read lock on target table.
      Attempt to execute the same statement for already existing
      target table with triggers caused server crashes.
      Also concurrent execution of CREATE TABLE ... SELECT statement
      and other statements involving target table suffered from
      various races (some of which might've led to deadlocks).
      Finally, attempt to execute CREATE TABLE ... SELECT in case
      when a temporary table with same name was already present
      led to the insertion of data into this temporary table and
      creation of empty non-temporary table.
       
      All above problems stemmed from the old implementation of CREATE
      TABLE ... SELECT in which we created, opened and locked target
      table without any special protection in a separate step and not
      with the rest of tables used by this statement.
      This underminded deadlock-avoidance approach used in server
      and created window for races. It also excluded target table
      from prelocking causing problems with trigger execution.
        
      The patch solves these problems by implementing new approach to
      handling of CREATE TABLE ... SELECT for base tables.
      We try to open and lock table to be created at the same time as
      the rest of tables used by this statement. If such table does not
      exist at this moment we create and place in the table cache special
      placeholder for it which prevents its creation or any other usage
      by other threads.
      
      We still use old approach for creation of temporary tables.
      
      Also note that we decided to postpone introduction of some tests
      for concurrent behaviour of CREATE TABLE ... SELECT till 5.1.
      The main reason for this is absence in 5.0 ability to set @@debug
      variable at runtime, which can be circumvented only by using several
      test files with individual .opt files. Since the latter is likely
      to slowdown test-suite unnecessary we chose not to push this tests
      into 5.0, but run them manually for this version and later push
      their optimized version into 5.1
      8b93e52e
  3. 19 Mar, 2007 1 commit
    • evgen@moonbone.local's avatar
      sql_insert.cc: · 31b9145a
      evgen@moonbone.local authored
        Removed wrong fix for the bug#27006.
        The bug was added by the fix for the bug#19978 and fixed by Monty on 2007/02/21.
      trigger.test, trigger.result:
        Corrected test case for the bug#27006.
      31b9145a
  4. 16 Mar, 2007 1 commit
  5. 06 Mar, 2007 2 commits
    • malff/marcsql@weblab.(none)'s avatar
      Manual merge · 82c1c023
      malff/marcsql@weblab.(none) authored
      82c1c023
    • malff/marcsql@weblab.(none)'s avatar
      Bug#8407 (Stored functions/triggers ignore exception handler) · b216d959
      malff/marcsql@weblab.(none) authored
      Bug 18914 (Calling certain SPs from triggers fail)
      Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02')
      Bug 21825 (Incorrect message error deleting records in a table with a
        trigger for inserting)
      Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency
        error)
      Bug 25345 (Cursors from Functions)
      
      
      This fix resolves a long standing issue originally reported with bug 8407,
      which affect the behavior of Stored Procedures, Stored Functions and Trigger
      in many different ways, causing symptoms reported by all the bugs listed.
      In all cases, the root cause of the problem traces back to 8407 and how the
      server locks tables involved with sub statements.
      
      Prior to this fix, the implementation of stored routines would:
      - compute the transitive closure of all the tables referenced by a top level
      statement
      - open and lock all the tables involved
      - execute the top level statement
      "transitive closure of tables" means collecting:
      - all the tables,
      - all the stored functions,
      - all the views,
      - all the table triggers
      - all the stored procedures
      involved, and recursively inspect these objects definition to find more
      references to more objects, until the list of every object referenced does
      not grow any more.
      This mechanism is known as "pre-locking" tables before execution.
      The motivation for locking all the tables (possibly) used at once is to
      prevent dead locks.
      
      One problem with this approach is that, if the execution path the code
      really takes during runtime does not use a given table, and if the table is
      missing, the server would not execute the statement.
      This in particular has a major impact on triggers, since a missing table
      referenced by an update/delete trigger would prevent an insert trigger to run.
      
      Another problem is that stored routines might define SQL exception handlers
      to deal with missing tables, but the server implementation would never give
      user code a chance to execute this logic, since the routine is never
      executed when a missing table cause the pre-locking code to fail.
      
      With this fix, the internal implementation of the pre-locking code has been
      relaxed of some constraints, so that failure to open a table does not
      necessarily prevent execution of a stored routine.
      
      In particular, the pre-locking mechanism is now behaving as follows:
      
      1) the first step, to compute the transitive closure of all the tables
      possibly referenced by a statement, is unchanged.
      
      2) the next step, which is to open all the tables involved, only attempts
      to open the tables added by the pre-locking code, but silently fails without
      reporting any error or invoking any exception handler is the table is not
      present. This is achieved by trapping internal errors with
      Prelock_error_handler
      
      3) the locking step only locks tables that were successfully opened.
      
      4) when executing sub statements, the list of tables used by each statements
      is evaluated as before. The tables needed by the sub statement are expected
      to be already opened and locked. Statement referencing tables that were not
      opened in step 2) will fail to find the table in the open list, and only at
      this point will execution of the user code fail.
      
      5) when a runtime exception is raised at 4), the instruction continuation
      destination (the next instruction to execute in case of SQL continue
      handlers) is evaluated.
      This is achieved with sp_instr::exec_open_and_lock_tables()
      
      6) if a user exception handler is present in the stored routine, that
      handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be
      trapped by stored routines. If no handler exists, then the runtime execution
      will fail as expected.
      
      With all these changes, a side effect is that view security is impacted, in
      two different ways.
      
      First, a view defined as "select stored_function()", where the stored
      function references a table that may not exist, is considered valid.
      The rationale is that, because the stored function might trap exceptions
      during execution and still return a valid result, there is no way to decide
      when the view is created if a missing table really cause the view to be invalid.
      
      Secondly, testing for existence of tables is now done later during
      execution. View security, which consist of trapping errors and return a
      generic ER_VIEW_INVALID (to prevent disclosing information) was only
      implemented at very specific phases covering *opening* tables, but not
      covering the runtime execution. Because of this existing limitation,
      errors that were previously trapped and converted into ER_VIEW_INVALID are
      not trapped, causing table names to be reported to the user.
      This change is exposing an existing problem, which is independent and will
      be resolved separately.
      b216d959
  6. 12 Jan, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #25398: crash in a trigger when using trigger fields · 86ef1cbf
      igor@olga.mysql.com authored
      in a select list.
      The objects of the Item_trigger_field class inherited the implementations
      of the methods copy_or_same, get_tmp_table_item and get_tmp_table_field
      from the class Item_field while they rather should have used the default
      implementations defined for the base class Item.
      It could cause catastrophic problems for triggers that used SELECTs
      with select list containing trigger fields such as NEW.<table column>
      under DISTINCT.
      86ef1cbf
  7. 21 Dec, 2006 1 commit
  8. 21 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug#23556: TRUNCATE TABLE still maps to DELETE · 5e0f4e53
      gkodinov/kgeorge@macbook.gmz authored
       This is the 5.0 part of the fix.
       Currently TRUNCATE command will not call
       delete_all_rows() in the handler (that implements
       the "fast" TRUNCATE for InnoDB) when there are
       triggers on the table.
       As decided by the architecture team TRUNCATE must
       use "fast" TRUNCATE even when there are triggers.
       Thus it must ignore the triggers. 
       Made TRUNCATE to ignore the triggers and call
       delete_all_rows() for all storage engines
       to maintain engine consistency.
      5e0f4e53
  9. 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
    • holyfoot/hf@mysql.com/deer.(none)'s avatar
    • 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
  10. 19 Oct, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#20028 (Function with select return no data) · ea0998ca
      malff/marcsql@weblab.(none) authored
      This patch reverts a change introduced by Bug 6951, which incorrectly
      set thd->abort_on_warning for stored procedures.
      
      As per internal discussions about the SQL_MODE=TRADITIONAL,
      the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE
      trigger.
      
      Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE
      have been included or revised, to reflect the intended behavior.
      
      (reposting approved patch, to work around source control issues, no review needed)
      ea0998ca
  11. 21 Sep, 2006 1 commit
    • dlenev@mockturtle.local's avatar
      Fix for bug#20670 "UPDATE using key and invoking trigger that modifies · 091ed9fb
      dlenev@mockturtle.local authored
      this key does not stop" (version for 5.0 only).
      
      UPDATE statement which WHERE clause used key and which invoked trigger
      that modified field in this key worked indefinetely.
      
      This problem occured because in cases when UPDATE statement was
      executed in update-on-the-fly mode (in which row is updated right
      during evaluation of select for WHERE clause) the new version of
      the row became visible to select representing WHERE clause and was
      updated again and again.
      We already solve this problem for UPDATE statements which does not
      invoke triggers by detecting the fact that we are going to update
      field in key used for scanning and performing update in two steps,
      during the first step we gather information about the rows to be
      updated and then doing actual updates. We also do this for
      MULTI-UPDATE and in its case we even detect situation when such
      fields are updated in triggers (actually we simply assume that
      we always update fields used in key if we have before update
      trigger).
      
      The fix simply extends this check which is done in check_if_key_used()/
      QUICK_SELECT_I::check_if_keys_used() routine/method in such way that
      it also detects cases when field used in key is updated in trigger.
      As nice side-effect we have more precise and thus more optimal
      perfomance-wise check for the MULTI-UPDATE.
      Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were
      renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to
      better reflect that boolean predicate.
      
      Note that this check is implemented in much more elegant way in 5.1 
      091ed9fb
  12. 25 Aug, 2006 1 commit
    • andrey@example.com's avatar
      Fix for bug#21795: SP: sp_head::is_not_allowed_in_function() contains · f115ecf8
      andrey@example.com authored
      erroneous check
      
      Problem: Actually there were two problems in the server code. The check
      for SQLCOM_FLUSH in SF/Triggers were not according to the existing
      architecture which uses sp_get_flags_for_command() from sp_head.cc .
      This function was also missing a check for SQLCOM_FLUSH which has a
      problem combined with prelocking. This changeset fixes both of these
      deficiencies as well as the erroneous check in
      sp_head::is_not_allowed_in_function() which was a copy&paste error.
      f115ecf8
  13. 24 Aug, 2006 1 commit
  14. 23 Aug, 2006 1 commit
  15. 29 Jun, 2006 1 commit
  16. 28 Jun, 2006 2 commits
    • 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
    • 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
  17. 16 Jun, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug#13479 "REPLACE activates UPDATE trigger, not the DELETE and · 59d20e26
      dlenev@mysql.com authored
      INSERT triggers".
      
      In cases when REPLACE was internally executed via update and table had
      on update (on delete) triggers defined we exposed the fact that such
      optimization used by callng on update (not calling on delete) triggers.
      Such behavior contradicts our documentation which describes REPLACE as
      INSERT with optional DELETE.
      
      This fix just disables this optimization for tables with on delete triggers.
      The optimization is still applied for tables which have on update but have
      no on delete triggers, we just don't invoke on update triggers in this case
      and thus don't expose information about optimization to user.
      
      Also added test coverage for values returned by ROW_COUNT() function (and
      thus for values returned by mysql_affected_rows()) for various forms of
      INSERT.
      59d20e26
  18. 12 May, 2006 1 commit
  19. 19 Apr, 2006 2 commits
  20. 18 Apr, 2006 1 commit
  21. 12 Apr, 2006 1 commit
    • kroki@mysql.com's avatar
      Bug#16461: connection_id() does not work properly inside trigger · c8e22ff7
      kroki@mysql.com authored
      CONNECTION_ID() was implemented as a constant Item, i.e. an instance of
      Item_static_int_func class holding value computed at creation time.
      Since Items are created on parsing, and trigger statements are parsed
      on table open, the first connection to open a particular table would
      effectively set its own CONNECTION_ID() inside trigger statements for
      that table.
      
      Re-implement CONNECTION_ID() as a class derived from Item_int_func, and
      compute connection_id on every call to fix_fields().
      c8e22ff7
  22. 29 Mar, 2006 1 commit
    • dlenev@mysql.com's avatar
      Proposed fix for bug #17764 "Trigger crashes MyISAM table" · 17785d16
      dlenev@mysql.com authored
      A table with an on insert trigger was reported as crashed when the insert
      was processed with bulk insert mode on (handler::start_bulk_insert).
      The trigger was also selecting from the same table, and that caused
      the "crash".
      The same problem was present when an insert statement, which was processed
      in bulk mode, also used a stored function that was reading the same table.
      
      This fix disables bulk inserts if a statement uses functions or invokes
      triggers. Implementing more granular checks will require much more code and
      therefore can hardly be done in 5.0
      17785d16
  23. 24 Mar, 2006 1 commit
  24. 04 Mar, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug #17866 "Problem with renaming table with triggers with fully · efe09006
      dlenev@mysql.com authored
      qualified subject table" which was introduced during work on bug #13525
      "Rename table does not keep info of triggers".
      
      The bug was caused by the fact that during reconstruction of CREATE TRIGGER
      statement stored in .TRG file which happened during RENAME TABLE we damaged
      trigger definition in case when it contained fully qualified name of subject
      table (see comment for sql_yacc.yy for more info).
      efe09006
  25. 27 Feb, 2006 1 commit
  26. 24 Feb, 2006 1 commit
  27. 28 Jan, 2006 1 commit
  28. 24 Jan, 2006 1 commit
  29. 05 Jan, 2006 1 commit
    • monty@mysql.com's avatar
      Review fixes of new pushed code · 6e22e29d
      monty@mysql.com authored
      - Fixed tests
      - Optimized new code
      - Fixed some unlikely core dumps
      - Better bug fixes for:
        - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
        - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
      6e22e29d
  30. 11 Dec, 2005 1 commit
  31. 22 Nov, 2005 2 commits
    • bell@sanja.is.com.ua's avatar
      7bd691f1
    • bell@sanja.is.com.ua's avatar
      Fix for BUG#13549 "Server crash with nested stored procedures · 2bcd6897
      bell@sanja.is.com.ua authored
      if inner routine has more local variables than outer one, and
      one of its last variables was used as argument to NOT operator".
      
      THD::spcont was non-0 when we were parsing stored routine/trigger
      definition during execution of another stored routine. This confused
      methods of Item_splocal and forced them use wrong runtime context.
      Fix ensures that we always have THD::spcont equal to zero during
      routine/trigger body parsing. This also allows to avoid problems
      with errors which occur during parsing and SQL exception handlers.
      2bcd6897
  32. 17 Nov, 2005 1 commit
  33. 14 Sep, 2005 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug #12704 "Server crashes during trigger execution". · e231ebe5
      dlenev@mysql.com authored
      This bug occurs when some trigger for table used by DML statement is created
      or changed while statement was waiting in lock_tables(). In this situation
      prelocking set which we have calculated becames invalid which can easily lead
      to errors and even in some cases to crashes.
      
      With proposed patch we no longer silently reopen tables in lock_tables(),
      instead caller of lock_tables() becomes responsible for reopening tables and
      recalculation of prelocking set.
      e231ebe5
  34. 02 Sep, 2005 1 commit
    • konstantin@mysql.com's avatar
      Implement WL#2661 "Prepared Statements: Dynamic SQL in Stored Procedures". · 38486e83
      konstantin@mysql.com authored
      The idea of the patch is to separate statement processing logic,
      such as parsing, validation of the parsed tree, execution and cleanup, 
      from global query processing logic, such as logging, resetting
      priorities of a thread, resetting stored procedure cache, resetting
      thread count of errors and warnings.
      This makes PREPARE and EXECUTE behave similarly to the rest of SQL
      statements and allows their use in stored procedures.
      This patch contains a change in behaviour:
      until recently for each SQL prepared statement command, 2 queries
      were written to the general log, e.g.
      [Query]   prepare stmt from @stmt_text;
      [Prepare] select * from t1 <-- contents of @stmt_text
      The chagne was necessary to prevent [Prepare] commands from being written
      to the general log when executing a stored procedure with Dynamic SQL.
      We should consider whether the old behavior is preferrable and probably
      restore it.
      This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
      in Dynamic SQL reported before it was disabled).
      38486e83