An error occurred fetching the project authors.
  1. 01 Oct, 2008 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#39182: Binary log producing incompatible character set query · dc6a5ff8
      Ramil Kalimullin authored
      from stored procedure. 
      
      Problem: we replace all references to local variables in stored procedures     
      with NAME_CONST(name, value) logging to the binary log. However, if the
      value's collation differs we might get an 'illegal mix of collation'           
      error as we don't pass the collation to the function.
      
      Fix: pass the value's collation to NAME_CONST().
      
      Note: actually we should pass to NAME_CONST() the value's derivation as well.
      It's impossible without the parser modifying. Now we always set the 
      derivation to DERIVATION_IMPLICIT, the same as local variables have.
      dc6a5ff8
  2. 29 Sep, 2008 1 commit
    • Alexey Botchkov's avatar
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row · b6f4b1c0
      Alexey Botchkov authored
           JOIN for the subselect wasn't cleaned if we came upon an error
           during sub_select() execution. That leads to the assertion failure
           in close_thread_tables()
      
           part of the 6.0 code backported
      
      per-file comments:
        mysql-test/r/sp-error.result
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
          test result
      
        mysql-test/t/sp-error.test
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
          test case
      
        sql/sp_head.cc
      Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
          lex->unit.cleanup() call added if not substatement
      b6f4b1c0
  3. 11 Aug, 2008 1 commit
    • Marc Alff's avatar
      Bug#38296 (low memory crash with many conditions in a query) · 394691cd
      Marc Alff authored
      This fix is for 5.0 only : back porting the 6.0 patch manually
      
      The parser code in sql/sql_yacc.yy needs to be more robust to out of
      memory conditions, so that when parsing a query fails due to OOM,
      the thread gracefully returns an error.
      
      Before this fix, a new/alloc returning NULL could:
      - cause a crash, if dereferencing the NULL pointer,
      - produce a corrupted parsed tree, containing NULL nodes,
      - alter the semantic of a query, by silently dropping token values or nodes
      
      With this fix:
      - C++ constructors are *not* executed with a NULL "this" pointer
      when operator new fails.
      This is achieved by declaring "operator new" with a "throw ()" clause,
      so that a failed new gracefully returns NULL on OOM conditions.
      
      - calls to new/alloc are tested for a NULL result,
      
      - The thread diagnostic area is set to an error status when OOM occurs.
      This ensures that a request failing in the server properly returns an
      ER_OUT_OF_RESOURCES error to the client.
      
      - OOM conditions cause the parser to stop immediately (MYSQL_YYABORT).
      This prevents causing further crashes when using a partially built parsed
      tree in further rules in the parser.
      
      No test scripts are provided, since automating OOM failures is not
      instrumented in the server.
      Tested under the debugger, to verify that an error in alloc_root cause the
      thread to returns gracefully all the way to the client application, with
      an ER_OUT_OF_RESOURCES error.
      394691cd
  4. 14 Jul, 2008 1 commit
    • Marc Alff's avatar
      Bug#35577 (CREATE PROCEDURE causes either crash or syntax error depending on · 0816ee6d
      Marc Alff authored
      build)
      
      The crash was caused by freeing the internal parser stack during the parser
      execution.
      This occured only for complex stored procedures, after reallocating the parser
      stack using my_yyoverflow(), with the following C call stack:
      - MYSQLparse()
      - any rule calling sp_head::restore_lex()
      - lex_end()
      - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs)
      
      The root cause is the implementation of stored procedures, which breaks the
      assumption from 4.1 that there is only one LEX structure per parser call.
      
      The solution is to separate the LEX structure into:
      - attributes that represent a statement (the current LEX structure),
      - attributes that relate to the syntax parser itself (Yacc_state),
      so that parsing multiple statements in stored programs can create multiple
      LEX structures while not changing the unique Yacc_state.
      
      Now, Yacc_state and the existing Lex_input_stream are aggregated into
      Parser_state, a structure that represent the complete state of the (Lexical +
      Syntax) parser.
      0816ee6d
  5. 20 May, 2008 1 commit
  6. 15 May, 2008 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#36570: Parse error of CREATE PROCEDURE stmt with comments on \ · 573828aa
      cmiller@zippy.cornsilk.net authored
      	slave
      
      The stored-routine code took the contents of the (lowest) parser
      and copied it directly to the binlog, which causes problems if there
      is a special case of interpretation at the parser level -- which 
      there is, in the "/*!VER */" comments.  The trailing "*/" caused
      errors on the slave, naturally.
      
      Now, since by that point we have /properly/ created parse-tree (as 
      the rest of the server should do!) for the stored-routine CREATE, we
      can construct a perfect statement from that information, instead of
      writing uncertain information from an unknown parser state.  
      Fortunately, there's already a function nearby that does exactly 
      that.
      ---
      Update for Bug#36570.  Qualify routine names with db name when
      writing to the binlog ONLY if the source text is qualified.
      573828aa
  7. 16 Apr, 2008 1 commit
    • kostja@bodhi.(none)'s avatar
      WL#4165 "Prepared statements: validation". · 7289eccf
      kostja@bodhi.(none) authored
      Add metadata validation to ~20 more SQL commands. Make sure that
      these commands actually work in ps-protocol, since until now they
      were enabled, but not carefully tested.
      Fixes the ml003 bug found by Matthias during internal testing of the
      patch.
      7289eccf
  8. 22 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#30217: Views: changes in metadata behaviour · 340906f4
      anozdrin/alik@quad. authored
      between 5.0 and 5.1.
        
      The problem was that in the patch for Bug#11986 it was decided
      to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
      This approach however turned out to be quite difficult to implement
      properly. The main problem is to preserve the same IS-output after
      dump/restore.
        
      So, the fix is to rollback to the previous functionality, but also
      to fix it to support multi-character-set-queries properly. The idea
      is to generate INFORMATION_SCHEMA-query from the item-tree after
      parsing view declaration. The IS-query should:
        - be completely in UTF8;
        - not contain character set introducers.
        
      For more information, see WL4052.
      340906f4
  9. 19 Feb, 2008 2 commits
  10. 30 Jan, 2008 1 commit
    • kostja@dipika.(none)'s avatar
      A fix and a test case for Bug#34166 Server crash in SHOW OPEN TABLES and · b46ce809
      kostja@dipika.(none) authored
      pre-locking.
      
      The crash was caused by an implicit assumption in check_table_access() that
      table_list parameter is always a part of lex->query_tables.
      
      When iterating over the passed list of tables, check_table_access() used
      to stop only when lex->query_tables_last_not_own was reached. 
      In case of pre-locking, lex->query_tables_last_own is not NULL and points
      to some element of lex->query_tables. When the parameter
      of check_table_access() was not part of lex->query_tables, loop invariant
      could never be violated and a crash would happen when the current table
      pointer would point beyond the end of the provided list.
      
      The fix is to change the signature of check_table_access() to also accept
      a numeric limit of loop iterations, similarly to check_grant(), and 
      supply this limit in all places when we want to check access of tables
      that are outside lex->query_tables, or just want to check access to one table.
      b46ce809
  11. 23 Jan, 2008 1 commit
    • malff@lambda.hsd1.co.comcast.net.'s avatar
      Bug#33618 (Crash in sp_rcontext) · c3ad0cac
      malff@lambda.hsd1.co.comcast.net. authored
      Bug 33983 (Stored Procedures: wrong end <label> syntax is accepted)
      
      The server used to crash when REPEAT or another control instruction
      was used in conjunction with labels and a LEAVE instruction.
      
      The crash was caused by a missing "pop" of handlers or cursors in the
      code representing the stored program. When executing the code in a loop,
      this missing "pop" would result in a stack overflow, corrupting memory.
      
      Code generation has been fixed to produce the missing h_pop/c_pop
      instructions.
      
      Also, the logic checking that labels at the beginning and the end of a
      statement are matched was incorrect, causing Bug 33983.
      End labels, when used, must match the label used at the beginning of a block.
      c3ad0cac
  12. 14 Dec, 2007 2 commits
  13. 12 Dec, 2007 1 commit
    • kostja@bodhi.(none)'s avatar
      Bug#12713 "Error in a stored function called from a SELECT doesn't · ebb9c5d9
      kostja@bodhi.(none) authored
      cause ROLLBACK of statement", part 1. Review fixes.
      
      Do not send OK/EOF packets to the client until we reached the end of 
      the current statement.
      This is a consolidation, to keep the functionality that is shared by all 
      SQL statements in one place in the server.
      Currently this functionality includes:
      - close_thread_tables()
      - log_slow_statement().
      
      After this patch and the subsequent patch for Bug#12713, it shall also include:
      - ha_autocommit_or_rollback()
      - net_end_statement()
      - query_cache_end_of_result().
      
      In future it may also include:
      - mysql_reset_thd_for_next_command().
      ebb9c5d9
  14. 19 Nov, 2007 1 commit
  15. 13 Nov, 2007 1 commit
  16. 01 Nov, 2007 1 commit
    • davi@endora.local's avatar
      Bug#30882 Dropping a temporary table inside a stored function may cause a server crash · cc007acb
      davi@endora.local authored
      If a stored function that contains a drop temporary table statement
      is invoked by a create temporary table of the same name may cause
      a server crash. The problem is that when dropping a table no check
      is done to ensure that table is not being used by some outer query
      (or outer statement), potentially leaving the outer query with a
      reference to a stale (freed) table.
      
      The solution is when dropping a temporary table, always check if
      the table is being used by some outer statement as a temporary
      table can be dropped inside stored procedures.
      
      The check is performed by looking at the TABLE::query_id value for
      temporary tables. To simplify this check and to solve a bug related
      to handling of temporary tables in prelocked mode, this patch changes
      the way in which this member is used to track the fact that table is
      used/unused. Now we ensure that TABLE::query_id is zero for unused
      temporary tables (which means that all temporary tables which were
      used by a statement should be marked as free for reuse after it's
      execution has been completed).
      cc007acb
  17. 30 Oct, 2007 1 commit
  18. 21 Oct, 2007 1 commit
  19. 19 Oct, 2007 1 commit
  20. 18 Oct, 2007 1 commit
    • davi@moksha.com.br's avatar
      Bug#21557 entries in the general query log truncated at 1000 characters. · dd135211
      davi@moksha.com.br authored
      The general log write function (general_log_print) uses printf style
      arguments which need to be pre-processed, meaning that the all arguments
      are copied to a single buffer and the problem is that the buffer size is
      constant (1022 characters) but queries can be much larger then this.
      
      The solution is to introduce a new log write function that accepts a
      buffer and it's length as arguments. The function is to be used when
      a formatted output is not required, which is the case for almost all
      query write-to-log calls.
      
      This is a incompatible change with respect to the log format of prepared
      statements.
      dd135211
  21. 17 Oct, 2007 1 commit
  22. 11 Oct, 2007 1 commit
  23. 09 Oct, 2007 1 commit
    • davi@virtua-cwbas201-21-158-74.ctb.virtua.com.br's avatar
      Bug#28318 CREATE FUNCTION (UDF) requires a schema · fd3c6b18
      Bug#29816 Syntactically wrong query fails with misleading error message
      
      The core problem is that an SQL-invoked function name can be a <schema
      qualified routine name> that contains no <schema name>, but the mysql
      parser insists that all stored procedures (function, procedures and
      triggers) must have a <schema name>, which is not true for functions.
      This problem is especially visible when trying to create a function
      or when a query contains a syntax error after a function call (in the
      same query), both will fail with a "No database selected" message if
      the session is not attached to a particular schema, but the first
      one should succeed and the second fail with a "syntax error" message.
      
      Part of the fix is to revamp the sp name handling so that a schema
      name may be omitted for functions -- this means that the internal
      function name representation may not have a dot, which represents
      that the function doesn't have a schema name. The other part is
      to place schema checks after the type (function, trigger or procedure)
      of the routine is known.
      fd3c6b18
  24. 28 Sep, 2007 1 commit
  25. 31 Aug, 2007 1 commit
    • anozdrin/alik@ibm.opbmk's avatar
      Fix for BUG#25843: changing default database between PREPARE and EXECUTE · d6f94b06
      anozdrin/alik@ibm.opbmk authored
      of statement breaks binlog.
      
      There were two problems discovered by this bug:
      
        1. Default (current) database is not fixed at the creation time.
           That leads to wrong output of DATABASE() function.
      
        2. Database attributes (@@collation_database) are not fixed at
           the creation time. That leads to wrong resultset.
      
      Binlog breakage and Query Cache wrong output happened because of
      the first problem.
      
      The fix is to remember the current database at the PREPARE-time and
      set it each time at EXECUTE.
      d6f94b06
  26. 29 Aug, 2007 1 commit
    • davi@moksha.local's avatar
      Bug#21975 Grant and revoke statements are non-transactional · cb7486b4
      davi@moksha.local authored
      Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
      Bug#17244 GRANT gives strange error message when used in a stored function
      
      GRANT/REVOKE statements are non-transactional (no explicit transaction
      boundaries) in nature and hence are forbidden inside stored functions and
      triggers, but they weren't being effectively forbidden. Furthermore, the
      absence of implict commits makes changes made by GRANT/REVOKE statements to
      not be rolled back.
      
      The implemented fix is to issue a implicit commit with every GRANT/REVOKE
      statement, effectively prohibiting these statements in stored functions
      and triggers. The implicit commit also fixes the replication bug, and looks
      like being in concert with the behavior of DDL and administrative statements.
      
      Since this is a incompatible change, the following sentence should be
      added to the Manual in the very end of the 3rd paragraph, subclause
      13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
      MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."
      
      Patch contributed by Vladimir Shebordaev
      cb7486b4
  27. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2
  28. 30 Jul, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      (pushing for Andrei) · 9a0e6ec6
      gkodinov/kgeorge@magare.gmz authored
      Bug #27417 thd->no_trans_update.stmt lost value inside of SF-exec-stack
        
      Once had been set the flag might later got reset inside of a stored routine 
      execution stack.
      The reason was in that there was no check if a new statement started at time 
      of resetting.
      The artifact affects most of binlogable DML queries. Notice, that multi-update 
      is wrapped up within
        bug@27716 fix, multi-delete bug@29136.
        
      Fixed with saving parent's statement flag of whether the statement modified 
      non-transactional table, and unioning (merging) the value with that was gained 
      in mysql_execute_command.
        
      Resettling thd->no_trans_update members into thd->transaction.`member`;
      Asserting code;
      Effectively the following properties are held.
        
      1. At the end of a substatement thd->transaction.stmt.modified_non_trans_table
         reflects the fact if such a table got modified by the substatement.
         That also respects THD::really_abort_on_warnin() requirements.
      2. Eventually thd->transaction.stmt.modified_non_trans_table will be computed as
         the union of the values of all invoked sub-statements.
         That fixes this bug#27417;
      
      Computing of thd->transaction.all.modified_non_trans_table is refined to base to 
      the stmt's value for all the case including insert .. select statement which 
      before the patch had an extra issue bug@28960.
      Minor issues are covered with mysql_load, mysql_delete, and binloggin of insert in
      to temp_table select. 
        
      The supplied test verifies limitely, mostly asserts. The ultimate testing is defered
      for bug@13270, bug@23333.
      9a0e6ec6
  29. 29 Jul, 2007 2 commits
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #30120. · 1eb20fc0
      gshchepa/uchum@gleb.loc authored
      SP with local variables with non-ASCII names crashed the server.
      
      The server replaces SP local variable names with NAME_CONST calls
      when putting statements into the binary log. It used UTF8-encoded
      item names as variable names for the replacement inside NAME_CONST
      calls. However, statement string may be encoded by any
      known character set by the SET NAMES statement.
      The server used byte length of UTF8-encoded names to increment
      the position in the query string that led to array index overrun.
      1eb20fc0
    • gshchepa/uchum@gleb.loc's avatar
      sp_head.cc: · 898a0fbf
      gshchepa/uchum@gleb.loc authored
        Post-merge fix.
      898a0fbf
  30. 28 Jul, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#29856: Insufficient buffer space led to a server crash. · 12366629
      evgen@moonbone.local authored
      The subst_spvars function is used to create query string with SP variables 
      substituted with their values. This string is used later for the binary log
      and for the query cache. The problem is that the
      query_cache_send_result_to_client function requires some additional space
      after the query to store database name and query cache flags. This 
      space wasn't reserved by the subst_spvars function which led to a memory
      corruption and crash.
      
      Now the subst_spvars function reserves additional space for the query cache.
      12366629
  31. 16 Jul, 2007 1 commit
  32. 12 Jul, 2007 2 commits
    • kostja@bodhi.(none)'s avatar
      A fix and a test case for Bug#26141 mixing table types in trigger · 5ab4b6f1
      kostja@bodhi.(none) authored
      causes full table lock on innodb table.
      Also fixes Bug#28502 Triggers that update another innodb table 
      will block on X lock unnecessarily (duplciate).
      Code review fixes.
      
      Both bugs' synopses are misleading: InnoDB table is
      not X locked. The statements, however, cannot proceed concurrently, 
      but this happens due to lock conflicts for tables used in triggers,
      not for the InnoDB table. 
      
      If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
      AFTER INSERT, competing for different resources (e.g. two distinct
      MyISAM tables), then these two triggers would not be able to execute
      concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
      not be able to run concurrently. 
      The problem had other side-effects (see respective bug reports).
      
      This behavior was a consequence of a shortcoming of the pre-locking
      algorithm, which would not distinguish between different DML operations
      (e.g. INSERT and DELETE) and pre-lock all the tables
      that are used by any trigger defined on the subject table.
      
      The idea of the fix is to extend the pre-locking algorithm to keep track,
      for each table, what DML operation it is used for and not
      load triggers that are known to never be fired.
      5ab4b6f1
    • anozdrin/alik@ibm.'s avatar
      Fix for 5.1 for BUG#10491: Server returns data as charset binary · 3f2e94c4
      anozdrin/alik@ibm. authored
      SHOW CREATE TABLE or SELECT FROM I_S.
      
      This is the last patch for this bug, which depends on the big
      CS patch and was pending.
      
      The problem was that SHOW CREATE statements returned original
      queries in the binary character set. That could cause the query
      to be unreadable.
      
      The fix is to use original character_set_client when sending
      the original query to the client. In order to preserve the query
      in mysqldump, 'binary' character set results should be set when
      issuing SHOW CREATE statement. If either source or destination
      character set is 'binary' , no conversion is performed.
      The idea is that since the source character set is no longer
      'binary', we fix the destination character set to still produce
      valid dumps.
      3f2e94c4
  33. 28 Jun, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Patch for the following bugs: · 9fae9ef6
      anozdrin/alik@ibm. authored
        - BUG#11986: Stored routines and triggers can fail if the code
          has a non-ascii symbol
        - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
        - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
        - BUG#21249: Character set of SP-var can be ignored
        - BUG#25212: Character set of string constant is ignored (stored routines)
        - BUG#25221: Character set of string constant is ignored (triggers)
      
      There were a few general problems that caused these bugs:
      1. Character set information of the original (definition) query for views,
         triggers, stored routines and events was lost.
      2. mysqldump output query in client character set, which can be
         inappropriate to encode definition-query.
      3. INFORMATION_SCHEMA used strings with mixed encodings to display object
         definition;
      
      1. No query-definition-character set.
      
      In order to compile query into execution code, some extra data (such as
      environment variables or the database character set) is used. The problem
      here was that this context was not preserved. So, on the next load it can
      differ from the original one, thus the result will be different.
      
      The context contains the following data:
        - client character set;
        - connection collation (character set and collation);
        - collation of the owner database;
      
      The fix is to store this context and use it each time we parse (compile)
      and execute the object (stored routine, trigger, ...).
      
      2. Wrong mysqldump-output.
      
      The original query can contain several encodings (by means of character set
      introducers). The problem here was that we tried to convert original query
      to the mysqldump-client character set.
      
      Moreover, we stored queries in different character sets for different
      objects (views, for one, used UTF8, triggers used original character set).
      
      The solution is
        - to store definition queries in the original character set;
        - to change SHOW CREATE statement to output definition query in the
          binary character set (i.e. without any conversion);
        - introduce SHOW CREATE TRIGGER statement;
        - to dump special statements to switch the context to the original one
          before dumping and restore it afterwards.
      
      Note, in order to preserve the database collation at the creation time,
      additional ALTER DATABASE might be used (to temporary switch the database
      collation back to the original value). In this case, ALTER DATABASE
      privilege will be required. This is a backward-incompatible change.
      
      3. INFORMATION_SCHEMA showed non-UTF8 strings
      
      The fix is to generate UTF8-query during the parsing, store it in the object
      and show it in the INFORMATION_SCHEMA.
      
      Basically, the idea is to create a copy of the original query convert it to
      UTF8. Character set introducers are removed and all text literals are
      converted to UTF8.
      
      This UTF8 query is intended to provide user-readable output. It must not be
      used to recreate the object.  Specialized SHOW CREATE statements should be
      used for this.
      
      The reason for this limitation is the following: the original query can
      contain symbols from several character sets (by means of character set
      introducers).
      
      Example:
      
        - original query:
          CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
      
        - UTF8 query (for INFORMATION_SCHEMA):
          CREATE VIEW v1 AS SELECT 'Hello' AS c1;
      9fae9ef6
  34. 18 Jun, 2007 1 commit
  35. 14 Jun, 2007 2 commits
    • anozdrin/alik@ibm.'s avatar
      Part of patch for BUG#11986: make sp_head::m_body_begin pointer · 754e9788
      anozdrin/alik@ibm. authored
      private and provide a setter for it. The setter will be used to
      construct UTF-query in the following patches.
      754e9788
    • anozdrin/alik@ibm.'s avatar
      This the 4-th patch in scope of CS patch (BUG#11986). · 62e3e462
      anozdrin/alik@ibm. authored
      The patch contains the following changes:
        - Introduce auxilary functions to convenient work with character sets:
          - resolve_charset();
          - resolve_collation();
          - get_default_db_collation();
        - Introduce lex_string_set();
        - Refactor Table_trigger_list::process_triggers() &
          sp_head::execute_trigger() to be consistent with other code;
        - Move reusable code from add_table_for_trigger() into
          build_trn_path(), check_trn_exists() and load_table_name_for_trigger()
          to be used in the following patch.
        - Rename triggers_file_ext and trigname_file_ext into TRN_EXT and
          TRG_EXT respectively.
      62e3e462