1. 28 Jul, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · c867301b
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug16581
      c867301b
    • kroki/tomash@moonlight.intranet's avatar
      Bug#16581: deadlock: server and client both read from connection in · d06001b1
      kroki/tomash@moonlight.intranet authored
                 'conc_sys' test
      
      Concurrent execution of SELECT involing at least two INFORMATION_SCHEMA
      tables, DROP DATABASE statement and DROP TABLE statement could have
      resulted in stalled connection for this SELECT statement.
      
      The problem was that for the first query of a join there was a race
      between select from I_S.TABLES and DROP DATABASE, and the error (no
      such database) was prepared to be send to the client, but the join
      processing was continued.  On second query to I_S.COLUMNS there was a
      race with DROP TABLE, but this error (no such table) was downgraded to
      warning, and thd->net.report_error was reset.  And so neither result
      nor error was sent to the client.
      
      The solution is to stop join processing once it is clear we are going
      to report a error, and also to downgrade to warnings file system errors
      like 'no such database' (unless we are in the 'SHOW' command), because
      I_S is designed not to use locks and the query to I_S should not abort
      if something is dropped in the middle.
      
      No test case is provided since this bug is a result of a race, and is
      timing dependant.  But we test that plain SHOW TABLES and SHOW COLUMNS
      give a error if there is no such database or a table respectively.
      d06001b1
  2. 27 Jul, 2006 3 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
    • anozdrin/alik@booka.'s avatar
      Don't complain in the error log about IM shutdown unless · 7b34bbc4
      anozdrin/alik@booka. authored
      BUG#20761 is fixed.
      7b34bbc4
  3. 24 Jul, 2006 3 commits
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · 6d05e32d
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug14702
      6d05e32d
    • kroki/tomash@moonlight.intranet's avatar
      BUG#14702: misleading error message when syntax error in · 89ea3b01
      kroki/tomash@moonlight.intranet authored
                 CREATE PROCEDURE
      
      The bug was fixed already.  This changeset adds a test case.
      89ea3b01
    • kostja@bodhi.local's avatar
      A fix and a test case for Bug#15752 "Lost connection to MySQL server · 2ce1a07c
      kostja@bodhi.local authored
      when calling a SP from C API"
      
      The bug was caused by lack of checks for misuse in mysql_real_query. 
      A stored procedure always returns at least one result, which is the 
      status of execution of the procedure itself.
      This result, or so-called OK packet, is similar to a result
      returned by INSERT/UPDATE/CREATE operations: it contains the overall
      status of execution, the number of affected rows and the number of
      warnings. The client test program attached to the bug did not read this 
      result and ivnoked the next query. In turn, libmysql had no check for 
      such scenario and mysql_real_query was simply trying to send that query 
      without reading the pending response, thus messing up the communication
      protocol.
      
      The fix is to return an error from mysql_real_query when it's called
      prior to retrieval of all pending results.
      2ce1a07c
  4. 21 Jul, 2006 1 commit
  5. 20 Jul, 2006 1 commit
  6. 17 Jul, 2006 2 commits
  7. 13 Jul, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · a3ea06db
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug18630
      a3ea06db
    • 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
  8. 12 Jul, 2006 3 commits
  9. 11 Jul, 2006 8 commits
  10. 10 Jul, 2006 15 commits