An error occurred fetching the project authors.
  1. 27 Feb, 2007 1 commit
    • cbell/Chuck@mysql_cab_desk.'s avatar
      BUG#20141 "User-defined variables are not replicated properly for · d13c3b94
      cbell/Chuck@mysql_cab_desk. authored
                SF/Triggers in SBR mode."
      BUG#14914 "SP: Uses of session variables in routines are not always replicated"
      BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated
                correctly"
      
      This patch corrects a minor error in the previous patch for BUG#20141. This patch
      corrects an errant code change to sp_head.cc. The comments for the first patch follow:
      
      User-defined variables used inside of stored functions/triggers in
      statements which did not update tables directly were not replicated.
      We also had problems with replication of user-defined variables which
      were used in triggers (or stored functions called from table-updating
      statements) more than once.
      
      This patch addresses the first issue by enabling logging of all
      references to user-defined variables in triggers/stored functions
      and not only references from table-updating statements.
      
      The second issue stemmed from the fact that for user-defined
      variables used from triggers or stored functions called from
      table-updating statements we were writing binlog events for each
      reference instead of only one event for the first reference.
      This problem is already solved for stored functions called from
      non-updating statements with help of "event unioning" mechanism.
      So the patch simply extends this mechanism to the case affected.
      It also fixes small problem in this mechanism which caused wrong
      logging of references to user-variables in cases when non-updating
      statement called several stored functions which used the same
      variable and some of these function calls were omitted from binlog
      as they were not updating any tables.
      d13c3b94
  2. 23 Feb, 2007 1 commit
    • cbell/Chuck@mysql_cab_desk.'s avatar
      BUG#20141 "User-defined variables are not replicated properly for SF/ · 4c6ced9f
      cbell/Chuck@mysql_cab_desk. authored
                 Triggers in SBR mode."
      BUG#14914 "SP: Uses of session variables in routines are not always
                 replicated"
      BUG#25167 "Dupl. usage of user-variables in trigger/function is not
                 replicated correctly"
      
      User-defined variables used inside of stored functions/triggers in
      statements which did not update tables directly were not replicated.
      We also had problems with replication of user-defined variables which
      were used in triggers (or stored functions called from table-updating
      statements) more than once.
      
      This patch addresses the first issue by enabling logging of all
      references to user-defined variables in triggers/stored functions
      and not only references from table-updating statements.
      
      The second issue stemmed from the fact that for user-defined
      variables used from triggers or stored functions called from
      table-updating statements we were writing binlog events for each
      reference instead of only one event for the first reference.
      This problem is already solved for stored functions called from
      non-updating statements with help of "event unioning" mechanism.
      So the patch simply extends this mechanism to the case affected.
      It also fixes small problem in this mechanism which caused wrong
      logging of references to user-variables in cases when non-updating
      statement called several stored functions which used the same
      variable and some of these function calls were omitted from binlog
      as they were not updating any tables.
      4c6ced9f
  3. 08 Jan, 2007 1 commit
    • guilhem@gbichot3.local's avatar
      Fix for BUG#19725 "Calls to SF in other database are not replicated · 3e760410
      guilhem@gbichot3.local authored
      correctly in some cases".
      In short, calls to a stored function located in another database
      than the default database, may fail to replicate if the call was made
      by SET, SELECT, or DO.
      Longer: when a stored function is called from a statement which does not go
      to binlog ("SET @A=somedb.myfunc()", "SELECT somedb.myfunc()",
      "DO somedb.myfunc()"), this crafted statement is binlogged:
      "SELECT myfunc();" (accompanied with a mention of the default database
      if there is one). So, if "somedb" is not the default database,
      the slave would fail to find myfunc(). The fix is to specify the
      function's database name in the crafted binlogged statement, like this:
      "SELECT somedb.myfunc();". Test added in rpl_sp.test.
      3e760410
  4. 23 Dec, 2006 1 commit
  5. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  6. 30 Nov, 2006 1 commit
  7. 17 Nov, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#19194 (Right recursion in parser for CASE causes excessive stack usage, · ce5a3fcc
      malff/marcsql@weblab.(none) authored
        limitation)
      
      Note to the reviewer
      ====================
      
      Warning: reviewing this patch is somewhat involved.
      Due to the nature of several issues all affecting the same area,
      fixing separately each issue is not practical, since each fix can not be
      implemented and tested independently.
      In particular, the issues with
      - rule recursion
      - nested case statements
      - forward jump resolution (backpatch list)
      are tightly coupled (see below).
      
      Definitions
      ===========
      
      The expression
        CASE expr
        WHEN expr THEN expr
        WHEN expr THEN expr
        ...
        END
      is a "Simple Case Expression".
      
      The expression
        CASE
        WHEN expr THEN expr
        WHEN expr THEN expr
        ...
        END
      is a "Searched Case Expression".
      
      The statement
        CASE expr
        WHEN expr THEN stmts
        WHEN expr THEN stmts
        ...
        END CASE
      is a "Simple Case Statement".
      
      The statement
        CASE
        WHEN expr THEN stmts
        WHEN expr THEN stmts
        ...
        END CASE
      is a "Searched Case Statement".
      
      A "Left Recursive" rule is like
        list:
            element
          | list element
          ;
      
      A "Right Recursive" rule is like
        list:
            element
          | element list
          ;
      
      Left and right recursion produces the same language, the difference only
      affects the *order* in which the text is parsed.
      
      In a descendant parser (usually written manually), right recursion works
      very well, and is typically implemented with a while loop.
      In an ascendant parser (yacc/bison) left recursion works very well,
      and is implemented naturally by the parser stack.
      In both cases, using the wrong type or recursion is very bad and should be
      avoided, as it causes technical issues with the parser implementation.
      
      Before this change
      ==================
      
      The "Simple Case Expression" and "Searched Case Expression" were both
      implemented by the "when_list" and "when_list2" rules, which are left
      recursive (ok).
      
      These rules, however, used lex->when_list instead of using the parser stack,
      which is more complex that necessary, and potentially dangerous because
      of other rules using THD::reset_lex.
      
      The "Simple Case Statement" and "Searched Case Statements" were implemented
      by the "sp_case", "sp_whens" and in part by "sp_proc_stmt" rules.
      Both cases were right recursive (bad).
      
      The grammar involved was convoluted, and is assumed to be the results of
      tweaks to get the code generation to work, but is not what someone would
      naturally write.
      
      In addition, using a common rule for both "Simple" and "Searched" case
      statements was implemented with sp_head::m_flags |= IN_SIMPLE_CASE,
      which is a flag and not a stack, and therefore does not take into account
      *nested* case statements. This leads to incorrect generated code, and either
      a server crash or an incorrect result.
      
      With regards to the backpatch mechanism, a *different* backpatch list was
      created for each jump from "WHEN expr THEN stmt" to "END CASE", which
      relied on the grammar to be right recursive.
      This is a mis-use of the backpatch list, since this list can resolve
      multiple references to the same target at once.
      
      The optimizer algorithm used to detect dead code in the "assembly" SQL
      instructions, implemented by sp_head::opt_mark(uint ip), was recursive
      in some cases (a conditional jump pointing forward to another conditional
      jump).
      In case of specially crafted code, like
      - a long list of "IF expr THEN stmt END IF"
      - a long CASE statement
      this would actually cause a server crash with a stack overflow.
      In general, having a stack that grows proportionally with user data (the
      SQL code given by the client in a CREATE PROCEDURE) is to be avoided.
      
      In debug builds only, creating a SP / SF / Trigger which had a significant
      amount of code would spend --literally-- several minutes in sp_head::create,
      because of the debug code involved with DBUG_PRINT("info", ("Code %s ...
      There are several issues with this code:
      - in a CASE with 5 000 WHEN, there are 15 000 instructions generated,
        which create a sting representation of the code which is 500 000 bytes
        long,
      - using a String instead of an io stream causes performances to degrade
        to a total server freeze, as time is spent doing realloc of a buffer
        always too short,
      - Printing a 500 000 long string in the debug log is too verbose,
      - Generating this string even when DBUG_PRINT is off is useless,
      - Having code that potentially can affect the server behavior, used with
        #ifdef / #endif is useful in some cases, but is also a bad practice.
      
      After this change
      =================
      
      "Case Expressions" (both simple and searched) have been simplified to
      not use LEX::when_list, which has been removed.
      
      Considering all the issues affecting case statements, the grammar for these
      has been totally re written.
      
      The existing actions, used to generate "assembly" sp_inst* code, have been
      preserved but moved in the new grammar, with the following changes:
      
      a) Bison rules are no longer shared between "Simple" and "Searched" case
      statements, because a stack instead of a flag is required to handle them.
      Nested statements are handled naturally by the parser stack, which by
      definition uses the correct rule in the correct context.
      Nested statements of the opposite type (simple vs searched) works correctly.
      The flag sp_head::IN_SIMPLE_CASE is no longer used.
      This is a step towards resolution of WL#2999, which correctly identified
      that temporary parsing flags do not belong to sp_head.
      The code in the action is shared by mean of the case_stmt_action_xxx()
      helpers.
      
      b) The backpatch mechanism, used to resolve forward jumps in the generated
      code, has been changed to:
      - create a label for the instruction following 'END CASE',
      - register each jump at the end of a "WHEN expr THEN stmt" in a *unique*
        backpatch list associated with the 'END CASE' label
      - resolve all the forward jumps for this label at once.
      
      In addition, the code involving backpatch has been commented, so that a
      reader can now understand by reading matching "Registering" and "Resolving"
      comments how the forward jumps are resolved and what target they resolve to,
      as this is far from evident when reading the code alone.
      
      The implementation of sp_head::opt_mark() has been revised to avoid
      recursive calls from jump instructions, and instead add the jump location
      to the list of paths to explore during the flow analysis of the instruction
      graph, with a call to sp_head::add_mark_lead().
      In addition, the flow analysis will stop if an instruction has already
      been marked as reachable, which the previous code failed to do in the
      recursive case.
      sp_head::opt_mark() is now private, to prevent new calls to this method from
      being introduced.
      
      The debug code present in sp_head::create() has been removed.
      Considering that SHOW PROCEDURE CODE is also available in debug builds,
      and can be used anytime regardless of the trace level, as opposed to
      "CREATE PROCEDURE" time and only if the trace was on,
      removing the code actually makes debugging easier (usable trace).
      
      Tests have been written to cover the parser overflow (big CASE),
      and to cover nested CASE statements.
      ce5a3fcc
  8. 09 Nov, 2006 1 commit
    • bar@mysql.com/bar.intranet.mysql.r18.ru's avatar
      Bug#23619 Incorrectly escaped multibyte characters in binary log break replication · a5de478d
      Problem: when embedding a character string with introducer with charset X
      into a SQL query which is generally in character set Y, the string constants
      were escaped according to their own character set (i.e.X), then after reading
      such a "mixed" query from binlog, the string constants were unescaped
      using character set of the query (i.e. Y), instead of X, which gave wrong
      results or even syntax errors with tricky charsets (e.g. sjis)
      Fix: when embedding a string constant of charset X into a query of charset Y,
      the string constant is now escaped according to character Y, instead of
      its own character set X.
      a5de478d
  9. 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
  10. 27 Sep, 2006 1 commit
  11. 07 Sep, 2006 1 commit
  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. 27 Jul, 2006 2 commits
    • anozdrin/alik@booka.'s avatar
      Fix for BUG#20438: CREATE statements for views, stored routines and triggers · 2d082d86
      anozdrin/alik@booka. authored
      can be not replicable.
      
      Now CREATE statements for writing in the binlog are created as follows:
        - the beginning of the statement is re-created;
        - the rest of the statement is copied from the original query.
      
      The problem appears when there is a version-specific comment (produced by
      mysqldump), started in the re-created part of the statement and closed in the
      copied part -- there is closing comment-parenthesis, but there is no opening
      one.
      
      The proper fix could be to re-create original statement, but we can not
      implement it in 5.0. So, for 5.0 the fix is just to cut closing
      comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE
      statement (so we are able to reuse existing code).
      2d082d86
    • anozdrin/alik@booka.'s avatar
      Fix for BUG#16211: Stored function return type for strings is ignored. · b7f403b5
      anozdrin/alik@booka. authored
      Fix for BUG#16676: Database CHARSET not used for stored procedures
      
      The problem in BUG#16211 is that CHARSET-clause of the return type for
      stored functions is just ignored.
      
      The problem in BUG#16676 is that if character set is not explicitly
      specified for sp-variable, the server character set is used instead
      of the database one.
      
      The fix has two parts:
      
        - always store CHARSET-clause of the return type along with the
          type definition in mysql.proc.returns column. "Always" means that
          CHARSET-clause is appended even if it has not been explicitly
          specified in CREATE FUNCTION statement (this affects BUG#16211 only).
      
          Storing CHARSET-clause if it is not specified is essential to avoid
          changing character set if the database character set is altered in
          the future.
      
          NOTE: this change is not backward compatible with the previous releases.
      
        - use database default character set if CHARSET-clause is not explicitly
          specified (this affects both BUG#16211 and BUG#16676).
      
          NOTE: this also breaks backward compatibility.
      b7f403b5
  14. 13 Jul, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Bug#18630: Arguments of suid routine calculated in wrong security · 4272d1ef
      kroki/tomash@moonlight.intranet authored
                 context.
      
      Routine arguments were evaluated in the security context of the routine
      itself, not in the caller's context.
      
      The bug is fixed the following way:
      
        - Item_func_sp::find_and_check_access() has been split into two
          functions: Item_func_sp::find_and_check_access() itself only
          finds the function and check that the caller have EXECUTE privilege
          on it.  New function set_routine_security_ctx() changes security
          context for SUID routines and checks that definer have EXECUTE
          privilege too.
      
        - new function sp_head::execute_trigger() is called from
          Table_triggers_list::process_triggers() instead of
          sp_head::execute_function(), and is effectively just as the
          sp_head::execute_function() is, with all non-trigger related code
          removed, and added trigger-specific security context switch.
      
        - call to Item_func_sp::find_and_check_access() stays outside
          of sp_head::execute_function(), and there is a code in
          sql_parse.cc before the call to sp_head::execute_procedure() that
          checks that the caller have EXECUTE privilege, but both
          sp_head::execute_function() and sp_head::execute_procedure() call
          set_routine_security_ctx() after evaluating their parameters,
          and restore the context after the body is executed.
      4272d1ef
  15. 29 Jun, 2006 1 commit
  16. 26 Jun, 2006 1 commit
    • 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
  17. 22 Jun, 2006 1 commit
    • konstantin@mysql.com's avatar
      A fix and a test case for Bug#15217 "Using a SP cursor on a table created · e20898a5
      konstantin@mysql.com authored
       with PREPARE fails with weird error".
      More generally, re-executing a stored procedure with a complex SP cursor query
      could lead to a crash.
      
      The cause of the problem was that SP cursor queries were not optimized 
      properly at first execution: their parse tree belongs to sp_instr_cpush,
      not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
      cursor was declared, not when it was opened. This led to loss of optimization
      transformations performed at first execution, as sp_instr_copen saw that the
      query is already "EXECUTED" and therefore either not ran first-execution 
      related blocks or wrongly rolled back the transformations caused by 
      first-execution code.
      The fix is to update the state of the parsed tree only when the tree is
      executed, as opposed to when the instruction containing the tree is executed.
      Assignment if i->state is moved to reset_lex_and_exec_core.
      e20898a5
  18. 14 Jun, 2006 1 commit
  19. 23 May, 2006 1 commit
  20. 15 May, 2006 2 commits
  21. 12 May, 2006 1 commit
  22. 06 May, 2006 1 commit
    • dlenev@mysql.com's avatar
      Fix for bug #17260 "Multiple invocations of triggers or stored functions · d8bc635e
      dlenev@mysql.com authored
      hog memory".
      
      During each invocation of stored function or trigger some objects which
      lifetime is one function call (e.g. sp_rcontext) were allocated on
      arena/memroot of calling statement. This led to consumption of fixed amount
      of memory for each function/trigger invocation and so statements which
      involve lot of them were hogging memory. This in its return led to OOM
      crashes or freezes.
      
      This fix introduces new memroot and arena for objects which lifetime is
      whole duration of function call. So all memory consumed by such objects
      is freed at the end of function call.
      d8bc635e
  23. 04 May, 2006 1 commit
  24. 19 Apr, 2006 1 commit
  25. 18 Apr, 2006 1 commit
    • pem@mysql.com's avatar
      Fixed BUG#18949: Test case sp-goto is disabled · a6fbde9d
      pem@mysql.com authored
        Removed sp-goto.test, sp-goto.result and all (disabled) GOTO code.
        Also removed some related code that's not needed any more (no possible
        unresolved label references any more, so no need to check for them).
        NB: Keeping the ER_SP_GOTO_IN_HNDLR in errmsg.txt; it might become useful
            in the future, and removing it (and thus re-enumerating error codes)
            might upset things. (Anything referring to explicit error codes.)
      a6fbde9d
  26. 07 Apr, 2006 1 commit
  27. 21 Mar, 2006 1 commit
  28. 02 Mar, 2006 2 commits
    • anozdrin@mysql.com's avatar
      Fix for BUG#13198: SP executes if definer does not exist. · c4cbe46b
      anozdrin@mysql.com authored
      Basically, this fix contains a test case and removing of a workaround
      for replication. This fix became possible after pushing WL#2897
      (Complete definer support in stored routines).
      c4cbe46b
    • anozdrin@mysql.com's avatar
      Implementation of WL#2897: Complete definer support in the stored routines. · fbb59203
      anozdrin@mysql.com authored
      The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION
      statements. Almost all support of definer in stored routines had been already
      done before this patch.
      
      NOTE: this patch changes behaviour of dumping stored routines in mysqldump.
      Before this patch, mysqldump did not dump DEFINER-clause for stored routines
      and this was documented behaviour. In order to get full information about stored
      routines, one should have dumped mysql.proc table. This patch changes this
      behaviour, so that DEFINER-clause is dumped.
      
      Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements
      before this patch, the clause is covered by additional version-specific comments.
      fbb59203
  29. 18 Feb, 2006 1 commit
    • guilhem@mysql.com's avatar
      Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)": · 56bed24c
      guilhem@mysql.com authored
      if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
      slave would stop and complain that error code between him and master mismatch. 
      To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
      call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
      And: minor wording change in the help text.
      This cset will cause conflicts in 5.1, I'll merge.
      56bed24c
  30. 09 Feb, 2006 1 commit
  31. 26 Jan, 2006 1 commit
    • pem@mysql.com's avatar
      Fixed on BUG#16568: Continue handler with simple CASE not working correctly · ff4e2892
      pem@mysql.com authored
        After trying multiple inheritance (to messy and hard make it work) and
        sublassing jump_if_not (worked, but ugly), decided to on this solution
        instead:
        Inserting an abstract sp_instr_opt_meta class as parent for all instructions
        with destinations makes it possible to handle a continuation pointer for
        sp_instr_set_case_expr too.
        Note: No special test case; the fix is captured by the changed behaviour of
        bug14643_2, and bug14498_4 (formerly disabled), in sp.test.
      ff4e2892
  32. 25 Jan, 2006 1 commit
  33. 20 Jan, 2006 1 commit
  34. 19 Jan, 2006 1 commit
  35. 12 Jan, 2006 1 commit
  36. 11 Jan, 2006 1 commit
  37. 10 Jan, 2006 1 commit