1. 12 Oct, 2007 3 commits
  2. 11 Oct, 2007 7 commits
  3. 10 Oct, 2007 11 commits
  4. 09 Oct, 2007 5 commits
    • davi@moksha.com.br's avatar
      Merge moksha.com.br:/Users/davi/mysql/push/mysql-5.0-runtime · c3d06676
      davi@moksha.com.br authored
      into  moksha.com.br:/Users/davi/mysql/push/bugs/31409-5.0
      c3d06676
    • davi@moksha.local's avatar
      Bug#31409 RENAME TABLE causes server crash or deadlock when used with HANDLER statements · 7252cbe1
      davi@moksha.local authored
      This deadlock occurs when a client issues a HANDLER ... OPEN statement
      that tries to open a table that has a pending name-lock on it by another
      client that also needs a name-lock on some other table which is already
      open and associated to a HANDLER instance owned by the first client.
      The deadlock happens because the open_table() function will back-off
      and wait until the name-lock goes away, causing a circular wait if some
      other name-lock is also pending for one of the open HANDLER tables.
      
      Such situation, for example, can be easily repeated by issuing a RENAME
      TABLE command in such a way that the existing table is already open
      as a HANDLER table by another client and this client tries to open
      a HANDLER to the new table name.
      
      The solution is to allow handler tables with older versions (marked for
      flush) to be closed before waiting for the name-lock completion. This is
      safe because no other name-lock can be issued between the flush and the
      check for pending name-locks.
      
      The test case for this bug is going to be committed into 5.1 because it
      requires a test feature only avaiable in 5.1 (wait_condition).
      7252cbe1
    • davi@moksha.local's avatar
      Merge moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime · efdd32ce
      davi@moksha.local authored
      into  moksha.local:/Users/davi/mysql/push/mysql-5.1-runtime
      efdd32ce
    • anozdrin/alik@station.'s avatar
      Fix merge. · 27ee6db9
      anozdrin/alik@station. authored
      27ee6db9
    • anozdrin/alik@station.'s avatar
      Merge station.:/mnt/raid/alik/MySQL/devel/5.0-rt · 1d63cac0
      anozdrin/alik@station. authored
      into  station.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged
      1d63cac0
  5. 08 Oct, 2007 3 commits
  6. 07 Oct, 2007 2 commits
  7. 05 Oct, 2007 2 commits
  8. 04 Oct, 2007 7 commits
    • davi@moksha.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.0-runtime · a8f2ba0f
      davi@moksha.local authored
      into  moksha.local:/Users/davi/mysql/push/mysql-5.0-runtime
      a8f2ba0f
    • davi@moksha.local's avatar
      Bug#21587 FLUSH TABLES causes server crash when used with HANDLER statements · 305ebc1e
      davi@moksha.local authored
      This bug is a symptom of the way handler's tables are managed. The
      most different aspect, compared to the conventional behavior, is that
      the handler's tables are long lived, meaning that their lifetimes are
      not bounded by the duration of the command that opened them. For this
      effect the handler code uses its own list (handler_tables instead of
      open_tables) to hold open handler tables so that the tables won't be
      closed at the end of the command/statement. Besides the handler_tables
      list, there is a hash (handler_tables_hash) which is used to associate
      handler aliases to tables and to refresh the tables upon demand (flush
      tables).
      
      The current implementation doesn't work properly with refreshed tables
      -- more precisely when flush commands are issued by other initiators.
      This happens because when a handler open or read statement is being
      processed, the associated table has to be opened or locked and, for this
      matter, the open_tables and handler_tables lists are swapped so that the
      new table being opened is inserted into the handler_tables list. But when
      opening or locking the table, if the refresh version is different from the
      thread refresh version then all used tables in the open_tables list (now
      handler_tables) are refreshed. In the "refreshing" process the handler
      tables are flushed (closed) without being properly unlinked from the
      handler hash.
      
      The current implementation also fails to properly discard handlers of
      dropped tables, but this and other problems are going to be addressed
      in the fixes for bugs 31397 and 31409.
      
      The chosen approach tries to properly save and restore the table state
      so that no table is flushed during the table open and lock operations.
      The logic is almost the same as before with the list swapping, but with
      a working glue code.
      
      The test case for this bug is going to be committed into 5.1 because it
      requires a test feature only avaiable in 5.1 (wait_condition).
      305ebc1e
    • joerg@trift2.'s avatar
      Merge trift2.:/MySQL/M50/push-5.0 · 571200d4
      joerg@trift2. authored
      into  trift2.:/MySQL/M51/push-5.1
      571200d4
    • joerg@trift2.'s avatar
      Merge trift2.:/MySQL/M50/mysql-5.0 · 82767a0a
      joerg@trift2. authored
      into  trift2.:/MySQL/M50/push-5.0
      82767a0a
    • anozdrin/alik@station.'s avatar
      Fix for BUG#31035: select from function, group by result crasher. · 707f0674
      anozdrin/alik@station. authored
      This actually, fix for the patch for bug-27354. The problem with
      the patch was that Item_func_sp::used_tables() was updated, but
      Item_func_sp::const_item() was not. So, for Item_func_sp, we had
      the following inconsistency:
        - used_tables() returned RAND_TABLE, which means that the item
          can produce "random" results;
        - but const_item() returned TRUE, which means that the item is
          a constant one.
      
      The fix is to change Item_func_sp::const_item() behaviour: it must
      return TRUE (an item is a constant one) only if a stored function
      is deterministic and each of its arguments (if any) is a constant
      item.
      707f0674
    • jperkin@production.mysql.com's avatar
      Merge production.mysql.com:/usersnfs/jperkin/bk/build/5.0 · 09560c65
      jperkin@production.mysql.com authored
      into  production.mysql.com:/usersnfs/jperkin/bk/build/5.1
      09560c65
    • jperkin@production.mysql.com's avatar
      Merge production.mysql.com:/usersnfs/jperkin/bk/build/5.0 · 583a3ef3
      jperkin@production.mysql.com authored
      into  production.mysql.com:/usersnfs/jperkin/bk/bug-27692/5.0
      583a3ef3