1. 20 Nov, 2007 4 commits
    • davi@endora.local's avatar
      Merge endora.local:/Users/davi/mysql/bugs/17244-5.1 · 3d31d4bc
      davi@endora.local authored
      into  endora.local:/Users/davi/mysql/mysql-5.1-runtime
      3d31d4bc
    • davi@endora.local's avatar
    • davi@endora.local's avatar
      Merge endora.local:/Users/davi/mysql/bugs/31397-5.1 · 9c111e37
      davi@endora.local authored
      into  endora.local:/Users/davi/mysql/mysql-5.1-runtime
      9c111e37
    • davi@endora.local's avatar
      Bug#31397 Inconsistent drop table behavior of handler tables. · 94e6e4ff
      davi@endora.local authored
      The problem is that DROP TABLE and other DDL statements failed to
      automatically close handlers associated with tables that were marked
      for reopen (FLUSH TABLES).
      
      The current implementation fails to properly discard handlers of
      dropped tables (that were marked for reopen) because it searches
      on the open handler tables list and using the current alias of the
      table being dropped. The problem is that it must not use the open
      handler tables list to search because the table might have been
      closed (marked for reopen) by a flush tables command and also it
      must not use the current table alias at all since multiple different
      aliases may be associated with a single table. This is specially
      visible when a user has two open handlers (using alias) of a same
      table and a flush tables command is issued before the table is
      dropped (see test case). Scanning the handler table list is also
      useless for dropping handlers associated with temporary tables,
      because temporary tables are not kept in the THD::handler_tables
      list.
      
      The solution is to simple scan the handlers hash table searching
      for, and deleting all handlers with matching table names if the
      reopen flag is not passed to the flush function, indicating that
      the handlers should be deleted. All matching handlers are deleted
      even if the associated the table is not open.
      94e6e4ff
  2. 15 Nov, 2007 2 commits
    • malff@lambda.hsd1.co.comcast.net.'s avatar
      Merge lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-base · 4ca38aff
      malff@lambda.hsd1.co.comcast.net. authored
      into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.1-rt-merge
      4ca38aff
    • anozdrin/alik@station.'s avatar
      A patch for BUG#19723: kill of active connection yields · e8343ca8
      anozdrin/alik@station. authored
      different error code depending on platform.
      
      On Mac OS X, KILL statement issued to kill the current
      connection would return a different error code and message than on
      other platforms ('MySQL server has gone away' instead of 'Shutdown
      in progress').
      
      The reason for this difference was that on Mac OS X we have macro
      SIGNAL_WITH_VIO_CLOSE defined. This macro forces KILL
      implementation to close the communication socket of the thread
      that is being killed. SIGNAL_WITH_VIO_CLOSE macro is defined on
      platforms where just sending a signal is not a reliable mechanism
      to interrupt the thread from sleeping on a blocking system call.
      In a nutshell, closing the socket is a hack to work around an
      operating system bug and awake the blocked thread no matter what.
      
      However, if the thread that is being killed is the same
      thread that issued KILL statement, closing the socket leads to a
      prematurely lost connection. At the same time it is not necessary
      to close the socket in this case, since the thread in question
      is not inside a blocking system call.
      
      The fix, therefore, is to not close the socket if the thread that
      is being killed is the same that issued KILL statement, even with
      defined SIGNAL_WITH_VIO_CLOSE.
      e8343ca8
  3. 14 Nov, 2007 3 commits
  4. 13 Nov, 2007 3 commits
  5. 12 Nov, 2007 20 commits
  6. 11 Nov, 2007 2 commits
  7. 10 Nov, 2007 5 commits
  8. 09 Nov, 2007 1 commit
    • mattiasj@mattiasj-laptop.(none)'s avatar
      Bug#32091: Security breach via directory changes · 6776cc19
      mattiasj@mattiasj-laptop.(none) authored
      Problem: the table's INDEX and DATA DIR was taken
        directly from the table's first partition.
        This allowed rename attack similar to
        bug#32111 when ALTER TABLE REMOVE PARTITIONING
      
      Solution: Silently ignore the INDEX/DATA DIR
        for the table. (Like some other storage engines
        do). 
        Partitioned tables do not support DATA/INDEX
        DIR on the table level, only on its partitions.
      6776cc19