- 15 Jan, 2009 3 commits
-
-
unknown authored
-
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. mysql-test/r/mysqlcheck.result: fixed mysqlcheck.test on Windows platforms. mysql-test/t/mysqlcheck.test: fixed mysqlcheck.test on Windows platforms.
-
unknown 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. client/mysqlcheck.c: Fix for 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. - check and set default charset if --default-character-set option given. - set default charset to "utf8" if there's --fix-table-name or --fix-db-name and no --default-character-set. mysql-test/r/mysqlcheck.result: Fix for 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. - test result. mysql-test/t/mysqlcheck.test: Fix for 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. - test case. sql/mysql_priv.h: Fix for 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. - check_n_cut_mysql50_prefix() introduced. sql/sql_table.cc: Fix for 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. - tablename_to_filename() code split into 2 parts - check_n_cut_mysql50_prefix() introduced to cut #mysql50# prefixes, used in the trigger code as well. sql/sql_trigger.cc: Fix for 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. - Table_triggers_list::check_n_load() - checking triggers assume a table/database name given may have "#mysql50#" prefix in some cases. - Table_triggers_list::change_table_name_in_triggers() - create .TRG file in new database directory and delete it in old one, as they may differ in case of "ALTER DATABASE ... UPGRADE DATA DIRECTORY NAME" - Table_triggers_list::change_table_name_in_trignames() - remove stale .TRN files in #mysql50#dbname directory in case of database upgrade - Table_triggers_list::change_table_name() - allow changing trigger's database in case of its upgrading sql/sql_trigger.h: Fix for 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. - new old_db_name parameter added in Table_triggers_list::change_table_name_in_trignames() and Table_triggers_list::change_table_name_in_triggers()
-
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. mysql-test/extra/rpl_tests/rpl_auto_increment.test: Add test code for BUG#41986 mysql-test/suite/rpl/r/rpl_auto_increment.result: update test result file for BUG#41986 sql/log_event.cc: set next_number_field before writing rows, and reset next_number_field after finished writing rows
-
- 13 Jan, 2009 7 commits
-
-
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
mysql-test/r/commit_1innodb.result: Increase commit count for row-based logging.
-
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. mysql-test/r/read_buffer_size_basic.result: test sets out of bounds value; we now throw a warning for this. This is a side-effect: before, the maximum was higher than the value we set here. The value was corrected to block-size, the maximum was not, hence the value was smaller than the maximum in this particular case. Now that we align the maxima at startup, the value in SET is larger than the (corrected) maximum, and we see a warning in this particular case. "This means we're doing it right." mysql-test/r/read_rnd_buffer_size_basic.result: test sets out of bounds value; we now throw a warning for this. This is a side-effect: before, the maximum was higher than the value we set here. The value was corrected to block-size, the maximum was not, hence the value was smaller than the maximum in this particular case. Now that we align the maxima at startup, the value in SET is larger than the (corrected) maximum, and we see a warning in this particular case. "This means we're doing it right." mysys/my_getopt.c: Do bounds-checking at start-up time so we'll catch and correct wonky default values and upper limits. sql/mysqld.cc: If 0 is a legal value per the docs, not to mention the default, we shouldn't give 1 as the lower limit. storage/innobase/handler/ha_innodb.cc: We are setting upper bounds here. ~0L gives -1. That is NOT what we want!
-
- 09 Jan, 2009 17 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
-
Mattias Jonsson authored
-
Mattias Jonsson authored
post push fix, added test found a valgrind warning sql/sql_partition.cc: Bug#40972: Partition pruning can lead to crash for bad dates Fix for valgrind warning
-
Sven Sandberg authored
Adding comments to some of the high-level functions in replication. sql/log_event.h: Fixed some mistakes in comments. sql/repl_failsafe.cc: Added comment for show_slave_hosts() sql/slave.cc: Added comment for show_master_info(), handle_slave_[sql|io](), and next_event() sql/sql_binlog.cc: Added @param comment. sql/sql_lex.h: Added comment for st_lex_master_info. sql/sql_repl.cc: Added comments for functions executing a statement: PURGE BINARY LOGS START SLAVE STOP SLAVE RESET SLAVE CHANGE MASTER RESET MASTER SHOW BINLOG EVENTS SHOW MASTER STATUS SHOW BINARY LOGS
-
Georgi Kodinov authored
No need to mask the error code returned by getting the next row to end of file when doing filesort. mysql-test/r/innodb_mysql_rbk.result: Bug #41543: test case mysql-test/t/innodb_mysql_rbk-master.opt: Bug #41543: test case mysql-test/t/innodb_mysql_rbk.test: Bug #41543: test case sql/filesort.cc: Bug #41543: No need to mask the error code returned by getting the next row to end of file when doing filesort.
-
Georgi Kodinov authored
When substituting system constant functions with a constant result the server was not expecting that the function may return NULL. Fixed by checking for NULL and returning Item_null (in the relevant collation) if the result of the system constant function was NULL. mysql-test/r/mysql.result: Bug #41437: test case mysql-test/t/mysql.test: Bug #41437: test case. Relies on database() returning NULL if no database is selected. sql/item_strfunc.cc: Bug #41437: Check for NULL result on evaluating the system constant function and return a constant NULL item.
-
Sven Sandberg authored
-
Sven Sandberg authored
-