A fix for Bug#35289: Too many connections -- wrong SQL state
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.
Showing
Please register or sign in to comment