1. 25 Mar, 2008 2 commits
  2. 22 Mar, 2008 2 commits
  3. 21 Mar, 2008 2 commits
  4. 20 Mar, 2008 1 commit
  5. 19 Mar, 2008 2 commits
  6. 18 Mar, 2008 6 commits
  7. 17 Mar, 2008 5 commits
    • davi@buzz.(none)'s avatar
      Post-merge fixes for Bug 35103 · b7f7c7dc
      davi@buzz.(none) authored
      b7f7c7dc
    • davi@buzz.(none)'s avatar
      Merge buzz.(none):/home/davi/mysql-5.0-runtime · df5cf2b1
      davi@buzz.(none) authored
      into  buzz.(none):/home/davi/mysql-5.1-runtime
      df5cf2b1
    • davi@mysql.com/endora.local's avatar
      44fe22e7
    • anozdrin/alik@quad.'s avatar
      Avoid races in connect.test. · 393c54db
      anozdrin/alik@quad. authored
      The problem was in a test case for Bug33507:
        - when the number of active connections reaches the limit,
          the server accepts only root connections. That's achieved by
          accepting a connection, negotiating with the client and
          checking user credentials. If it is not SUPER, the connection
          is dropped.
        - when the server accepts connection, it increases the counter;
        - when the server drops connection, it decreases the counter;
        - the race was in between of decreasing the counter and accepting
          new connection:
          - max_user_connections = 2;
          - 2 oridinary user connections accepted;
          - extra user connection is establishing;
          - server checked user credentials, and sent 'Too many connections'
            error;
          - the client receives the error and establishes extra SUPER user
            connection;
          - the server however didn't decrease the counter (the extra
            user connection still is "alive" in the server) -- so, the new
            SUPER-user connection, will be dropped, because it exceeds
            (max_user_connections + 1).
      
      The fix is to implement "safe connect", which makes several attempts
      to connect and use it in the test script.
      393c54db
    • anozdrin/alik@quad.'s avatar
      A patch for Bug#35329: connect does not set mysql_errno variable. · f2b39a5a
      anozdrin/alik@quad. authored
      The problem was that 'connect' command didn't set mysql_errno
      variable, thus the script was unable to determine whether connection
      was opened or not.
      
      The fix is to set this variable.
      
      Test cases will be added in the scope of Bug33507
      into connect.test file.
      f2b39a5a
  8. 14 Mar, 2008 2 commits
    • davi@mysql.com/endora.local's avatar
      Bug#35103 mysql_client_test::test_bug29948 causes sporadic failures · f23e3fd0
      davi@mysql.com/endora.local authored
      The problem was that the COM_STMT_SEND_LONG_DATA was sending a response
      packet if the prepared statement wasn't found in the server (due to
      reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE
      should not send any packets, even error packets should not be sent since
      they are not expected by the client API.
      
      The solution is to clear generated during the execution of the aforementioned
      commands and to skip resend of prepared statement commands. Another fix is
      that if the connection breaks during the send of prepared statement command,
      the command is not sent again since the prepared statement is no longer in the
      server.
      f23e3fd0
    • anozdrin/alik@quad.'s avatar
      A fix for Bug#35289: Too many connections -- wrong SQL state · d3575ce0
      anozdrin/alik@quad. authored
      in some case.
      
      ER_CON_COUNT_ERROR is defined with SQL state 08004. However, this SQL state is not always
      returned.
      
      This error can be thrown in two cases:
      
        1. when an ordinary user (a user w/o SUPER privilege) is connecting,
          and the number of active user connections is equal or greater than
          max_connections.
      
        2. when a user is connecting and the number of active user connections is
          already (max_connections + 1) -- that means that no more connections will
          be accepted regardless of the user credentials.
      
      In the 1-st case, SQL state is correct.
      
      The bug happens in the 2-nd case -- on UNIX the client gets 00000 SQL state, which is
      absolutely wrong (00000 means "not error SQL state); on Windows
      the client accidentally gets HY000 (which means "unknown SQL state).
      
      The cause of the problem is that the server rejects extra connection
      prior to read a packet with client capabilities. Thus, the server
      does not know if the client supports SQL states or not (if the client
      supports 4.1 protocol or not). So, the server supposes the worst and
      does not send SQL state at all.
      
      The difference in behavior on UNIX and Windows occurs because on Windows
      CLI_MYSQL_REAL_CONNECT() invokes create_shared_memory(), which returns
      an error (in default configuration, where shared memory is not configured).
      Then, the client does not reset this error, so when the connection is
      rejected, SQL state is HY000 (from the error from create_shared_memory()).
      
      The bug appeared after test case for Bug#33507 -- before that, this behavior
      just had not been tested.
      
      The fix is to 1) reset the error after create_shared_memory();
      2) set SQL state to 'unknown error' if it was not received from
      the server.
      
      A separate test case is not required, since the behavior is already
      tested in connect.test.
      
      Note for doc-team: the manual should be updated to say that under
      some circumstances, 'Too many connections' has HY000 SQL state.
      d3575ce0
  9. 13 Mar, 2008 6 commits
  10. 12 Mar, 2008 12 commits