1. 24 Aug, 2006 2 commits
  2. 23 Aug, 2006 2 commits
  3. 22 Aug, 2006 3 commits
    • malff/marcsql@weblab.(none)'s avatar
      Merge malff@bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 154bb53b
      malff/marcsql@weblab.(none) authored
      into  weblab.(none):/home/marcsql/TREE/mysql-5.0-8153
      154bb53b
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · 9c1b3f57
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21051-2
      9c1b3f57
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21051: RESET QUERY CACHE very slow when query_cache_type=0 · 0f0ddc39
      kroki/tomash@moonlight.intranet authored
      There were two problems: RESET QUERY CACHE took a long time to complete
      and other threads were blocked during this time.
      
      The patch does three things:
        1 fixes a bug with improper use of test-lock-test_again technique.
            AKA Double-Checked Locking is applicable here only in few places.
        2 Somewhat improves performance of RESET QUERY CACHE.
            Do my_hash_reset() instead of deleting elements one by one.  Note
            however that the slowdown also happens when inserting into sorted
            list of free blocks, should be rewritten using balanced tree.
        3 Makes RESET QUERY CACHE non-blocking.
            The patch adjusts the locking protocol of the query cache in the
            following way: it introduces a flag flush_in_progress, which is
            set when Query_cache::flush_cache() is in progress.  This call
            sets the flag on enter, and then releases the lock.  Every other
            call is able to acquire the lock, but does nothing if
            flush_in_progress is set (as if the query cache is disabled).
            The only exception is the concurrent calls to
            Query_cache::flush_cache(), that are blocked until the flush is
            over.  When leaving Query_cache::flush_cache(), the lock is
            acquired and the flag is reset, and one thread waiting on
            Query_cache::flush_cache() (if any) is notified that it may
            proceed.
      0f0ddc39
  4. 21 Aug, 2006 2 commits
    • dlenev@mockturtle.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · 320f8ccc
      dlenev@mockturtle.local authored
      into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg21216-2
      320f8ccc
    • dlenev@mockturtle.local's avatar
      Fix for bug#21216 "Simultaneous DROP TABLE and SHOW OPEN TABLES causes · 186fa6c2
      dlenev@mockturtle.local authored
      server to crash".
      
      Crash caused by assertion failure happened when one ran SHOW OPEN TABLES
      while concurrently doing DROP TABLE (or RENAME TABLE, CREATE TABLE LIKE
      or any other command that takes name-lock) in other connection.
      For non-debug version of server problem exposed itself as wrong output
      of SHOW OPEN TABLES statement (it was missing name-locked tables).
      Finally in 5.1 both debug and non-debug versions simply crashed in
      this situation due to NULL-pointer dereference.
      
      This problem was caused by the fact that table placeholders which were
      added to table cache in order to obtain name-lock had TABLE_SHARE::table_name
      set to 0. Therefore they broke assumption that this member is non-0 for
      all tables in table cache which was checked by assert in list_open_tables()
      (in 5.1 this function simply relies on it).
      The fix simply sets this member for such placeholders to appropriate value
      making this assumption true again.
      
      This patch also includes test for similar bug 12212 "Crash that happens
      during removing of database name from cache" reappeared in 5.1 as bug 19403.
      186fa6c2
  5. 19 Aug, 2006 1 commit
  6. 17 Aug, 2006 1 commit
  7. 15 Aug, 2006 1 commit
  8. 03 Aug, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#8153 (Stored procedure with subquery and continue handler, wrong result) · 21f00113
      malff/marcsql@weblab.(none) authored
      Before this fix,
      - a runtime error in a statement in a stored procedure with no error handlers
      was properly detected (as expected)
      - a runtime error in a statement with an error handler inherited from a non
      local runtime context (i.e., proc a with a handler, calling proc b) was
      properly detected (as expected)
      - a runtime error in a statement with a *local* error handler was executed
      as follows :
      a) the statement would succeed, regardless of the error condition, (bug)
      b) the error handler would be called (as expected).
      
      The root cause is that functions like my_messqge_sql would "forget" to set
      the thread flag thd->net.report_error to 1, because of the check involving
      sp_rcontext::found_handler_here().
      Failure to set this flag would cause, later in the call stack,
      in Item_func::fix_fields() at line 190, the code to return FALSE and consider
      that executing the statement was successful.
      
      With this fix :
      - error handling code, that was duplicated in different places in the code,
      is now implemented in sp_rcontext::handle_error(),
      - handle_error() correctly sets thd->net.report_error when a handler is
      present, regardless of the handler location (local, or in the call stack).
      
      A test case, bug8153_subselect, has been written to demonstrate the change
      of behavior before and after the fix.
      
      Another test case, bug8153_function_a, as also been writen.
      This test has the same behavior before and after the fix.
      This test has been written to demonstrate that the previous expected
      result of procedure bug18787, was incorrect, since select no_such_function()
      should fail and therefore not produce a result.
      
      The incorrect result for bug18787 has the same root cause as Bug#8153,
      and the expected result has been adjusted.
      21f00113
  9. 02 Aug, 2006 15 commits
  10. 01 Aug, 2006 9 commits
  11. 31 Jul, 2006 3 commits