- 21 Jan, 2009 1 commit
-
-
Serge Kozlov authored
clause server fires immediately after creating event and time between create and delete event sometimes is enough for firing. So adding STARTS clause moves first execution in future after drop of event 1. Added STARTS clause for CREATE EVENT. 2. Updated result file.
-
- 20 Jan, 2009 1 commit
-
-
Staale Smedseng authored
character_set_database !=character_set_server" is fixed.
-
- 16 Jan, 2009 10 commits
-
-
Timothy Smith authored
-
Timothy Smith authored
-
Timothy Smith authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
Georgi Kodinov authored
-
- 15 Jan, 2009 17 commits
-
-
Joerg Bruehe authored
This does not bring any contents changes, it is purely metadata which are affected. Details: Even within 5.0, most of these changesets did not cause file contents changes, because they were backports done for the "service pack" builds of 5.0.66sp1 and 5.0.72sp1. The "real" changesets are also already present in 5.1, so this upmerge doesn't change any contents. The only "real" changeset in 5.0 was a fix of the shell scripts used to configure bdb (BerkeleyDB). As we completele removed bdb from the 5.1 sources already, the affected files are not present in the 5.1 source tree, so this changeset also does not cause any contents changes.
-
Joerg Bruehe authored
this should not happen.
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
unknown authored
-
Georgi Kodinov authored
-
Davi Arnaut authored
mysql-test/r/cache_innodb.result: Update test case result.
-
Alexander Nozdrin authored
-
Joerg Bruehe authored
This is not the final merge of that release build, but we need early access to these tool fixes (use of "awk" in the BDB configuration).
-
Joerg Bruehe 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 8 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
-
Timothy Smith 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 3 commits
-
-
Timothy Smith authored
Use SELECT FROM INFORMATION_SCHEMA instead of SHOW VARIABLES LIKE to restrict values correctly.
-
Timothy Smith authored
partition_innodb_semi_consistent.test, which was overlooked in the innodb-5.1-ss3603 snapshot.
-
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. mysql-test/r/innodb_cache.result: Update test case result. mysql-test/r/query_cache.result: Add test case result for Bug#36326 mysql-test/t/query_cache.test: Add test case for Bug#36326 sql/mysql_priv.h: Add new flags. sql/sql_cache.cc: Remember the transaction and autocommit status stored in the packet. tests/mysql_client_test.c: Add test case for Bug#36326
-