1. 07 Dec, 2007 5 commits
  2. 06 Dec, 2007 2 commits
  3. 05 Dec, 2007 8 commits
  4. 04 Dec, 2007 2 commits
  5. 02 Dec, 2007 5 commits
  6. 01 Dec, 2007 15 commits
  7. 30 Nov, 2007 3 commits
    • davi@endora.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · af039c53
      davi@endora.local authored
      into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime
      af039c53
    • davi@endora.local's avatar
      Merge mysql.com:/Users/davi/mysql/bugs/22312-5.1 · 7bdb3219
      davi@endora.local authored
      into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime
      7bdb3219
    • anozdrin/alik@ibm.'s avatar
      A patch for BUG#32148: killing a query may be ineffective. · 8377c71f
      anozdrin/alik@ibm. authored
      The problem was that THD::killed was reset after a command was
      read from the socket, but before it was actually handled. That lead
      to a race: if another KILL statement was issued for this connection
      in the middle of reading from the socket and processing a command,
      THD::killed state would be cleaned.
      
      The fix is to move this cleanup into net_send_error() function.
      
      A sample test case exists in binlog_killed.test:
        - connection 1: start a new transaction on table t1;
        - connection 2: send query to the server (w/o waiting for the
          result) to update data in table t1 -- this query will be blocked
          since there is unfinished transaction;
        - connection 1: kill query in connection 2 and finish the transaction;
        - connection 2: get result of the previous query -- it should be
          the "query-killed" error.
      
      This test however contains race condition, which can not be fixed
      with the current protocol: there is no way to guarantee, that the
      server will receive and start processing the query in connection 2
      (which is intended to get blocked) before the KILL command (sent in
      the connection 1) will arrive. In other words, there is no way to
      ensure that the following sequence will not happen:
      
        - connection 1: start a new transaction on table t1;
        - connection 1: kill query in connection 2 and finish the transaction;
        - connection 2: send query to the server (w/o waiting for the
          result) to update data in table t1 -- this query will be blocked
          since there is unfinished transaction;
        - connection 2: get result of the previous query -- the query will
          succeed.
      
      So, there is no test case for this bug, since it's impossible
      to write a reliable test case under the current circumstances.
      8377c71f