| Bug #35289 | Too many connections -- wrong SQL state in some case | ||
|---|---|---|---|
| Submitted: | 14 Mar 2008 11:55 | Modified: | 4 Apr 2008 20:46 |
| Reporter: | Alexander Nozdrin | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: General | Severity: | S3 (Non-critical) |
| Version: | 5.1-bk | OS: | Any |
| Assigned to: | Alexander Nozdrin | CPU Architecture: | Any |
[14 Mar 2008 12:57]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/43995 ChangeSet@1.2565, 2008-03-14 15:58:27+03:00, anozdrin@quad. +2 -0 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.
[14 Mar 2008 13:42]
Kristofer Pettersson
Review on IRC. Approved for push.
[17 Mar 2008 14:22]
Alexander Nozdrin
Pushed into 5.1-runtime.
[26 Mar 2008 14:13]
Bugs System
Pushed into 5.1.24-rc
[27 Mar 2008 17:53]
Bugs System
Pushed into 6.0.5-alpha
[2 Apr 2008 12:44]
Alexander Nozdrin
Bug#35705 has been marked as a duplicate of this bug.
[4 Apr 2008 20:46]
Jon Stephens
Documented in the 5.1.23-ndb-6.3.11, 5.1.24, and 6.0.5 changelogs as follows:
In some cases, when too many clients tried to connect to the server, the
proper SQLSTATE code was not returned.
Description: 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. How to repeat: 1. Start the server with --max-connections=1 2. Connect two clients as SUPER-user (root); 3. Try to connect the 3rd client and note SQL state of the error. Suggested fix: 1. Since it's quite a major change in the server (in terms of possible consequences) to read client_capabilities before rejecting an extra connection, it's proposed to create a WL item for this task. (See also, Bug#26426). 2. However, the client should return HY000 SQL state on any platform intentionally in case of ER_CON_COUNT_ERROR.