1. 17 Mar, 2008 1 commit
  2. 14 Mar, 2008 1 commit
    • 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
  3. 13 Mar, 2008 4 commits
  4. 12 Mar, 2008 6 commits
  5. 10 Mar, 2008 1 commit
  6. 06 Mar, 2008 2 commits
    • davi@mysql.com/endora.local's avatar
      Bug#35103 mysql_client_test::test_bug29948 causes sporadic failures · 93a09928
      davi@mysql.com/endora.local authored
      Disable test case for bug 29948, which is causing sporadically
      failures in other tests inside mysql_client_test.
      93a09928
    • thek@adventure.(none)'s avatar
      Bug#25132 disabled query cache: Qcache_free_blocks = 1 · a13cba5a
      thek@adventure.(none) authored
      The initial value of free memory blocks in 0. When the query cache is enabled 
      a new memory block gets allocated and is assigned number 1. The free memory
      block is later split each time query cache memory is allocated for new blocks.
      This means that the free memory block counter won't be reduced to zero when
      the number of allocated blocks are zero, but rather one. To avoid confusion
      this patch changes this behavior so that the free memory block counter is
      reset to zero when the query cache is disabled.
      Note that when the query cache is enabled and resized the free memory block
      counter was still calculated correctly.
      a13cba5a
  7. 05 Mar, 2008 1 commit
  8. 04 Mar, 2008 5 commits
  9. 03 Mar, 2008 1 commit
  10. 29 Feb, 2008 2 commits
  11. 28 Feb, 2008 6 commits
  12. 27 Feb, 2008 7 commits
  13. 26 Feb, 2008 3 commits