- 15 Jan, 2009 9 commits
-
-
Davi Arnaut authored
-
Alexander Nozdrin authored
-
Davi Arnaut authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Davi Arnaut authored
-
Alexander Nozdrin authored
with mysql_change_user) to 5.0.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 14 Jan, 2009 7 commits
-
-
MySQL Build Team authored
-
Ramil Kalimullin authored
Post-fix test failure: fixed mysqlcheck.test on Windows platforms.
-
timothy.smith@sun.com authored
-
Chad MILLER authored
-
Ramil Kalimullin authored
bug#33094: Error in upgrading from 5.0 to 5.1 when table contains triggers and #41385: Crash when attempting to repair a #mysql50# upgraded table with triggers. Problem: 1. trigger code didn't assume a table name may have a "#mysql50#" prefix, that may lead to a failing ASSERT(). 2. "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME" failed for databases with "#mysql50#" prefix if any trigger. 3. mysqlcheck --fix-table-name didn't use UTF8 as a default character set that resulted in (parsing) errors for tables with non-latin symbols in their names and definitions of triggers. Fix: 1. properly handle table/database names with "#mysql50#" prefix. 2. handle --default-character-set mysqlcheck option; if mysqlcheck is launched with --fix-table-name or --fix-db-name set default character set to UTF8 if no --default-character-set option given. Note: if given --fix-table-name or --fix-db-name option, without --default-character-set mysqlcheck option default character set is UTF8.
-
He Zhenxing authored
-
He Zhenxing authored
The next number (AUTO_INCREMENT) field of the table for write rows events are not initialized, and cause some engines (innodb) not correctly update the tables's auto_increment value. This patch fixed this problem by honor next number fields if present.
-
- 13 Jan, 2009 8 commits
-
-
Davi Arnaut authored
The problem is that the query cache stores packets containing the server status of the time when the cached statement was run. This might lead to a wrong transaction status in the client side if a statement is cached during a transaction and is later served outside a transaction context (and vice-versa). The solution is to take into account the transaction status when storing in and serving from the query cache.
-
Chad MILLER authored
-
Matthias Leich authored
-
Davi Arnaut authored
-
Matthias Leich authored
41776 type_date.test may fail if run around midnight. into GCA tree.
-
Matthias Leich authored
41111 events_bugs fails sporadically on pushbuild into GCA tree
-
Matthias Leich authored
41932 funcs_1: is_collation_character_set_applicability path too long for tar into GCA tree
-
Matthias Leich authored
+ add workaround for bug 38124 + messages into the protocol when sessions are switched + replace error numbers by error names + reset of system variables to initial values per subtest + remove a file created by this test + minor improvements in structure and formatting
-
- 12 Jan, 2009 6 commits
-
-
Patrick Crews authored
Added cleanup of status variables to the end of binlog_database. Re-recorded .result file to account for cleanup statement. NOTE: binlog.binlog_innodb also has had an FLUSH STATUS; statement added to it as well, but adding this cleanup as a preventative measure.
-
Chad MILLER authored
Bug#36428: MY_MUTEX_INIT_FAST is used before initialization On some thread implementations, we need a fake mutex attri- bute as a placeholder, which we define as a global variable, "my_fast_mutexattr". Well. that must be initialized before used in any mutexes, and the ordering of initializations in the API function my_init() was wrong. Now, put my_thread_global_init(), which initializes the attri- butes that mutexes require.
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Davi Arnaut authored
-
Tatiana A. Nurnberg authored
Bounds-checks and blocksize corrections were applied to user-input, but constants in the server were trusted implicitly. If these values did not actually meet the requirements, the user could not set change a variable, then set it back to the (wonky) factory default or maximum by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT). Now checks also apply to the server's presets. Wonky values and maxima get corrected at startup. Consequently all non-offsetted values the user sees are valid, and users can set the variable to that exact value if they so desire.
-
- 09 Jan, 2009 10 commits
-
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Tatiana A. Nurnberg authored
-
Tatiana A. Nurnberg authored
-
Georgi Kodinov authored
-
Matthias Leich authored
2. Avoid bad effects of bug 41925 Warning 1366 Incorrect string value: ... for column processlist.info 3. Add poll routines which ensure that subtests meet stable scenarios. This does not change the sense of the subtests.
-
Tatiana A. Nurnberg authored
-