From: John H. Embretsen Date: May 20 2009 5:11pm Subject: Weekly Falcon bazaar merge List-Archive: http://lists.mysql.com/falcon/748 Message-Id: <4A1439DF.5090406@sun.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary_(ID_J9U09yWMs+Ce/wSAUb/NsA)" --Boundary_(ID_J9U09yWMs+Ce/wSAUb/NsA) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hi falconers, I just finished the weekly merge of our bazaar branches mysql-6.0 --> mysql-6.0-falcon --> mysql-6.0-falcon-team and mysql-6.0-falcon-team --> mysql-6.0-falcon Commit comments from merged revisions are attached to this E-mail. As always, please test your code tree for unusual problems such as compile errors or the like. The latest merge will appear in the public falcon branch on Launchpad within a couple of hours. You can create your own local branch from launchpad: bzr branch lp:~mysql/mysql-server/mysql-6.0-falcon (see https://code.launchpad.net/~mysql/mysql-server/mysql-6.0-falcon) Cheers and happy compiling, -- John H. Embretsen QA Engineer, Sun Microsystems --Boundary_(ID_J9U09yWMs+Ce/wSAUb/NsA) Content-type: text/plain; name=merged-from-falcon-team-2009-05-20.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=merged-from-falcon-team-2009-05-20.txt Merged 1 revision from mysql-6.0-falcon-team: ------------------------------------------------------------ revno: 2707 committer: Olav Sandstaa branch nick: falcon-bug44292 timestamp: Mon 2009-05-18 11:42:26 +0200 message: Fix for Bug#44292 falcon_bug_34351_C fails with assertion (false) in file RecordLocatorPage.cpp This crash was caused by an inconsistency in the RecordLocator page. In some situations the maxLine value was not updates when inserting new space management slots. This could cause later updates to the record locator page to introduce inconsistencies in the record index. This patch changes RecordLocatorPage::setIndexSlot() to handle situations where the slot to be inserted has a slot number larger than the maxLine value. Before this patch if a slot number that was larger than the current maxLine value was inserted, the maxLine value was not updated accordingly. The fix is to update the maxLine value based on the inserted slot number. --Boundary_(ID_J9U09yWMs+Ce/wSAUb/NsA) Content-type: text/plain; name=merged-from-main-2009-05-20.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=merged-from-main-2009-05-20.txt Merged 20 revisions from mysql-6.0: ------------------------------------------------------------ revno: 2778 committer: Alexander Nozdrin branch nick: 6.0-rt timestamp: Sat 2009-05-16 12:36:58 +0400 message: Merge from 6.0 ------------------------------------------------------------ revno: 2777 committer: Dmitry Lenev branch nick: mysql-6.0-bg44738 timestamp: Fri 2009-05-15 12:00:35 +0400 message: Fix for bug #44738 "fill_schema_table_from_frm() opens tables without lowercasing table name". In lower_case_table_names > 0 mode some queries to I_S left entries with incorrect key in table definition cache. This wasted memory and in combination with similar problem in CREATE TABLE (which also has peeked into table definition cache using non-normalized key) led to to spurious ER_TABLE_EXISTS_ERROR errors when one tried to create a table with the same name as a previously existing but dropped table (assuming that table name contained characters in upper case). This problem occured due to fact that fill_schema_table_from_frm() was not properly normalizing (lowercasing) database and table names which it used for lookups in table definition cache. This fix adds proper normalization to this function. It also solves similar problem in CREATE TABLE's code by ensuring that it uses properly normalized version of table name when it peeks into table definition cache instead of non-normalized one. ------------------------------------------------------------ revno: 2776 committer: Jon Olav Hauglid branch nick: mysql-6.0-runtime-bug21793 timestamp: Thu 2009-05-14 16:33:44 +0200 message: manual merge ------------------------------------------------------------ revno: 2775 committer: Jon Olav Hauglid branch nick: mysql-6.0-runtime-bug21793 timestamp: Thu 2009-05-14 16:27:03 +0200 message: Bug #21793 Missing CF_CHANGES_DATA and CF_STATUS_COMMAND for handful of commands CF_CHANGES_DATA and CF_STATUS_COMMAND flags added to the commands mentioned in the bug description. With the following two exceptions: 1) 4 commands do not exist: SQLCOM_RENAME_DB SQLCOM_LOAD_MASTER_DATA SQLCOM_LOAD_MASTER_TABLE SQLCOM_SHOW_COLUMN_TYPES 2) All SQLCOM_SHOW_* commands already had CF_STATUS_COMMAND, leaving only SQLCOM_BINLOG_BASE64_EVENT. Further, check_prepared_statement() in sql_prepare.cc has been simplified by taking advantage of the CF_STATUS_COMMAND flag. Note that no test case has been added. ------------------------------------------------------------ revno: 2774 committer: Davi Arnaut branch nick: mysql-6.0-runtime timestamp: Mon 2009-05-11 14:58:07 -0300 message: Merge from 6.0 main. ------------------------------------------------------------ revno: 2773 committer: Jon Olav Hauglid branch nick: mysql-6.0-runtime-bugged timestamp: Fri 2009-05-08 16:11:05 +0200 message: manual merge ------------------------------------------------------------ revno: 2772 committer: Jon Olav Hauglid branch nick: mysql-6.0-runtime-bugged timestamp: Fri 2009-05-08 15:34:08 +0200 message: Bug #31293 create logfile group/tablespace returns OK with warning when engine=myisam Bug title slightly misleading. The problem was that syntax errors (1064) were mistakenly generated for the following statements: CREATE TABLESPACE ALTER TABLESPACE DROP TABLESPACE CREATE LOGFILE GROUP ALTER LOGFILE GROUP DROP LOGFILE GROUP These statments used without any extra clauses gave syntax errors. Adding one or more clauses would remove the syntax error, even if those clauses are all defined as optional. The fix changes the grammar to accept statements without extra clauses so that the above statments give the proper error message used with engine=myisam: ERROR 1478 (HY000): Table storage engine 'MyISAM' does not support the create option 'TABLESPACE or LOGFILE GROUP' Note that the ENGINE clause was optional before this fix even if this does not match the current version of the reference manual where it is marked as required. The manual should therefore be updated marking the ENGINE clause as optional for all statements listed above. Parser.test appended with a test of various statements that should give error 1478 ER_ILLEGAL_HA_CREATE_OPTION, but before gave syntax error. ------------------------------------------------------------ revno: 2771 committer: Dmitry Lenev branch nick: mysql-6.0-runtime timestamp: Fri 2009-05-01 17:37:34 +0400 message: Follow-up for fix for bug "Bug#43138: DROP DATABASE failure does not clean up message list". Fixed drop.test failure under non-debug server by moving part of test dependent on debug-only feature to separate .test file, which won't be run for non-debug versions of server. ------------------------------------------------------------ revno: 2770 committer: Magne Mahre branch nick: mysql-6.0-runtime-fix42461 timestamp: Thu 2009-04-30 18:57:43 +0200 message: Bug #42461 Plugins: st_mysql_lex_string differs between plugin.h and m_string.h include/m_string.h and include/mysql/plugin.h had different definition of the type of the length attribute (size_t vs. unsigned int). Decided to use size_t as the common type, as this is the type used in the Single Unix Specification everywhere a string's length is given. No specific test case is added, as several existing test cases use MYSQL_LEX_STRING from plugins (in particular the maria suite). ------------------------------------------------------------ revno: 2769 committer: Magne Mahre branch nick: mysql-6.0-runtime-fix-backup-backup_log timestamp: Thu 2009-04-30 18:53:50 +0200 message: Added a test to check if the file name length exceeds the OS/platform maximum file name length. ------------------------------------------------------------ revno: 2768 committer: Alexander Nozdrin branch nick: 6.0-rt-bug43138.3 timestamp: Thu 2009-04-30 19:31:30 +0400 message: Fix for Bug#43138: DROP DATABASE failure does not clean up message list. The problem was that the high-level function mysql_rm_db() invoked low-level mysql_rm_table_part2(), which reported low-level error (Unknown table) if SE refused to delete a table. Also when mysql_rm_table_part2() reported an error, it didn't add corresponding warning into the list (because it is used from other places where such behaviour is required). The fix is to 1. Remove no_warnings_for_error usage from sql_table.cc 2. Improve internal error handler support in THD, so that a stack of error handlers is allowed. 3. Create an internal error handler (Drop_table_error_handler) to silence useless warnings. 4. Use the handler in DROP DATABASE and DROP TABLE statements. ------------------------------------------------------------ revno: 2767 committer: Alexander Nozdrin branch nick: 6.0-rt timestamp: Fri 2009-04-24 14:04:14 +0400 message: Pull from 6.0 ------------------------------------------------------------ revno: 2766 committer: Alexander Nozdrin branch nick: 6.0-rt timestamp: Wed 2009-04-22 13:22:10 +0400 message: Do not run the ndb, rpl_ndb test suites in regular builds ------------------------------------------------------------ revno: 2765 committer: Davi Arnaut branch nick: mysql-6.0-runtime timestamp: Mon 2009-04-06 20:03:28 -0300 message: Post-merge fix: remove reference to removed file. ------------------------------------------------------------ revno: 2764 committer: Davi Arnaut branch nick: mysql-6.0-runtime timestamp: Mon 2009-04-06 15:36:46 -0300 message: Remove unused and ancient files and facilities. ------------------------------------------------------------ revno: 2763 committer: Davi Arnaut branch nick: 41971-6.0 timestamp: Thu 2009-04-02 16:39:33 -0300 message: Bug#41971: Thread state on embedded server is always "Writing to net" The problem is that the state of a thread on a embedded server is always displayed as "Writing to net", which is wrong as there is no "network" in the embedded server. The solution is only exclude, on a embedded server, the thread state conditions that are related to network operations. Other thread states related to waiting on conditions or other operations are preserved. ------------------------------------------------------------ revno: 2762 committer: Alexander Nozdrin branch nick: 6.0-rt-bug37795.3 timestamp: Thu 2009-04-02 12:15:00 +0400 message: Patch for Bug#37795: main.innodb_mysql crashes randomly. It was a test case problem: one 'reap' statement was forgotten. ------------------------------------------------------------ revno: 2761 committer: Magne Mahre branch nick: mysql-6.0-runtime-fix33693 timestamp: Wed 2009-04-01 20:00:07 +0200 message: Bug #33693 general log name and location depend on PID file, not on predefined values The default name of the PID file was constructed, as documented, based on the hostname. This name was subsequently used as the base for the general log file name. If the name of the PID file was overridden in the configuration, and no explicit name was set for the general log file, the path location for the PID file was used also for the general log file. A new variable, 'default_logfile_name', has been introduced. This name is constructed based on the hostname, and is then used to construct both the PID file and the general log file. The general log file will now, unless explicitly set, be located in the server data directory (as documentated in the server docs) ------------------------------------------------------------ revno: 2760 committer: Alexander Nozdrin branch nick: 6.0-rt-bug39542.2 timestamp: Wed 2009-04-01 12:16:35 +0400 message: Patch for Bug#39542: main.trigger_compat fails sporadically on windows. The patch actually enhances mysqltest directives -- 'move_file' has been introduced. ------------------------------------------------------------ revno: 2759 committer: Magne Mahre branch nick: mysql-6.0-runtime-fix38124 timestamp: Tue 2009-03-31 18:47:35 +0200 message: Bug #38124 "general_log_file" variable silently unset when using expression When assigning the new string value to the variable, the Item::str_value member was used. This is not according to the protocol. str_value is an internal member used for temporary assignments, and is not consistently set for all string operations. It is set for constant strings, so it would work in these cases, but not for string functions (concat, substr, etc.) The correct approach is to use Item::val_str(..) to evaluate and retrieve the string. --Boundary_(ID_J9U09yWMs+Ce/wSAUb/NsA)--