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.
The problem is that since MyISAM's concurrent_insert is on by
default some concurrent SELECT statements might not see changes
made by INSERT statements in other connections, even if the
INSERT statement has returned.
The solution is to disable concurrent_insert so that INSERT
statements returns after the data is actually visible to other
statements.
When concurrent inserts were disabled, statements after an INSERT
were not put into the query cache. This happened because we do not
save the current data file length at statement start when
concurrent inserts are disabled. But we checked the always zero
local length against the real file length anyway.
Fixed by doing the check only if concurrent inserts are not diabled.
databases from 4.0 server
mysqldump treated a failure to set the results charset as a severe
error.
Now, don't try to set the charset for the SHOW CREATE TABLE statement,
if remote server's version is earlier than 4.1, which means it
doesn't support changing charsets.
table with backticks
(Thanks to Lu Jingdong, though I did not take his patch directly, as
it contained a significant flaw.)
It wasn't a backtick/parsing problem. We merely didn't anticipate
and allocate enough space to handle the optional "#mysql50#" table-
name prefix.
Now, allocate that extra space in case we need it when we look up
a legacy table to get its file's name.
than max_connections -- which results in user lockout.
The problem was that the variable thread_count that contains
the number of active threads was interpreted as a number of
active connections.
The fix is to introduce a new counter for active connections.
In cases when TRUNCATE was executed by invoking mysql_delete() rather
than by table recreation (for example, when TRUNCATE was issued on
InnoDB table with is referenced by foreign key) triggers were invoked.
In debug builds this also led to crash because of an assertion, which
assumes that some preliminary actions take place before trigger
invocation, which doesn't happen in case of TRUNCATE.
The fix is not to execute triggers in mysql_delete() when this
function is used by TRUNCATE.
ChangeSet@1.2565, 2008-03-11 20:20:49+01:00
Merge five.local.lan:/work/merge/mysql-5.0-funcs_1
into five.local.lan:/work/merge/mysql-5.1-funcs_1
MERGE: 1.1810.3473.26
ChangeSet@1.1810.3473.26, 2008-03-11 19:54:35+01:00
Post fix for
WL#4203 Reorganize and fix the data dictionary tests of
testsuite funcs_1
The final fix of
Bug#34532 Some funcs_1 tests do not clean up at end of testing
and some minor additional modifications are for
happens here
WL#4203 Reorganize and fix the data dictionary tests of
testsuite funcs_1
because the goal to fix
Bug#34532 Some funcs_1 tests do not clean up at end of testing
was partially missed.
Some minor additional modifications are for
WL#4304 Cleanup in funcs_1 tests
Problem: rpl_variables_stm.test used a character set and a collation which
are not included on all platforms.
Fix: replace the character set and collation by ones that are included on
all platforms. (rpl_variables_stm does not rely on which character set is
used, the only important aspect is the fact that it changes.)
