|
------------------------------------------------------------
revno: 3313 tags: clone-5.5.24-build committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.5-security timestamp: Thu 2012-04-12 15:04:22 +0200 message: Bug#13871079 RQG_MYISAM_DML_ALTER_VALGRIND FAILS ON VALGRIND PN PB2 The class Copy_field contains a String tmp, which may allocate memory on the heap. That means that all instances of Copy_field must be properly destroyed. Alas they are not. Solution: don't use Copy_field::tmp for copying from_field => tmp => to_field in do_field_string() ------------------------------------------------------------ revno: 3312 [merge] committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com> branch nick: merge-5.5-security timestamp: Thu 2012-04-12 14:04:12 +0300 message: merge mysql-5.5->mysql-5.5-security ------------------------------------------------------------ revno: 3097.126.65 committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com> branch nick: Bug12662190 timestamp: Thu 2012-04-12 11:07:39 +0530 message: BUG#12662190:COM_COMMIT IS NOT INCREMENTED FROM THE BINARY LOGS ON SLAVE, COM_BEGIN IS PROBLEM: -------- When binary log statements are replayed on the slave, BEGIN is represented in com_counters but COMMIT is not. Similarly in 'ROW' based replication 'INSERT','UPDATE',and 'DELETE' com_counters are not getting incremented when the binary log statements are replayed at slave. ANALYSIS: --------- In 'ROW' based replication for COMMIT,INSERT,UPDATE and DELETE operations following special events are invoked. Xid_log_event,Write_rows_log_event,Update_rows_log_event,Update_rows_log_event. The above mentioned events doesn't go through the parser where the 'COM_COUNTERS' are incremented. FIX: ----- Increment statements are added at appropriate events. Respective functions are listed below. 'Xid_log_event::do_apply_event' 'Write_rows_log_event::do_before_row_operations' 'Update_rows_log_event::do_before_row_operations' 'Delete_rows_log_event::do_before_row_operations' ------------------------------------------------------------ revno: 3097.126.64 committer: gopal.shankar@oracle.com branch nick: systemtables-5.5 timestamp: Wed 2012-04-11 15:53:17 +0530 message: Bug#11815557 60269: MYSQL SHOULD REJECT ATTEMPTS TO CREATE SYSTEM TABLES IN INCORRECT ENGINE PROBLEM: CREATE/ALTER TABLE currently can move system tables like mysql.db, user, host etc, to engines other than MyISAM. This is not completely supported as of now, by mysqld. When some of system tables like plugin, servers, event, func, *_priv, time_zone* are moved to innodb, mysqld restart crashes. Currently system tables can be moved to BLACKHOLE also!!!. ANALYSIS: The problem is that there is no check before creating or moving a system table to some particular engine. System tables are suppose to be residing in MyISAM. We can think of restricting system tables to exist only in MyISAM. But, there could be future needs of these system tables to be part of other engines by design. For eg, NDB cluster expects some tables to be on innodb or ndb engine. This calls for a solution, by which system tables can be supported by any desired engine, with minimal effort. FIX: The solution provides a handlerton interface using which, mysqld server can query particular storage engine handlerton for system tables that it supports. This way each storage engine layer can define their own system database and system tables. The check_engine() function uses the new handlerton function ha_check_if_supported_system_table() to check if db.tablename provided in the DDL is supported by the SE. Note: This fix has modified a test in help.test, which was moving mysql.help_* to innodb. The primary intention of the test was not to move them between engines. ------------------------------------------------------------ revno: 3097.126.63 committer: Manish Kumar<manish.4.kumar@oracle.com> branch nick: mysql timestamp: Tue 2012-04-10 16:15:06 +0530 message: BUG#13917335 - ASSERTION `REPORT_PORT != 0' FAILED IN NETWORK_INIT () Problem - The cause of the failure is mainly due to the assert added in the code as a result of the fix of the BUG-13333431. When we start the server with the --skip-networking option enabled we have the mysqld_port explicitly to 0. Since the value of report_port is set to mysqld_port, the assertion that (report_port!= 0) fails. Fix - the fix of the problem is to assert the not zero value of report_port only in the case the --skip-networking option is not used to start the mysqld server. ------------------------------------------------------------ revno: 3311 [merge] committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com> branch nick: merge-5.5-security timestamp: Tue 2012-04-10 14:46:21 +0300 message: empty weave merge mysql-5.1-security->mysql-5.5-security ------------------------------------------------------------ revno: 2661.768.80 [merge] committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com> branch nick: merge-5.1-security timestamp: Tue 2012-04-10 14:21:57 +0300 message: merge mysql-5.1->mysql-5.1-security ------------------------------------------------------------ revno: 2661.800.49 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.1-59107 timestamp: Mon 2012-04-09 16:42:41 +0530 message: Bug #11766072 59107: MYSQLSLAP CRASHES IF STARTED WITH NO ARGUMENTS ON WINDOWS This bug is a duplicate of Bug #31173, which was pushed to the mysql-trunk 5.6 on 4th Aug, 2010. This is just a back-port of the fix ------------------------------------------------------------ revno: 3310 [merge] committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com> branch nick: merge-5.5-security timestamp: Tue 2012-04-10 14:23:17 +0300 message: merge mysql-5.5->mysql-5.5-security ------------------------------------------------------------ revno: 3097.126.62 committer: Manish Kumar<manish.4.kumar@oracle.com> branch nick: mysql-5.5 timestamp: Tue 2012-04-10 11:44:17 +0530 message: BUG#13812374 - RPL.RPL_REPORT_PORT FAILS OCCASIONALLY ON PB2 Problem - this failure occured in the test added for the fix of the bug-13333431. The basic problem of the failure was the value of the report_port which persisted even after the end of the test (ie. rpl_end.inc). So this causes the assertion in the test to fail if it is executed again. Fix - restarted the server with the default value being passed to the report_port after testing the two expected case so that in the next run of the test we will not encounter the previous value of report_port. ------------------------------------------------------------ revno: 3097.126.61 [merge] committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.5-59107 timestamp: Mon 2012-04-09 16:43:54 +0530 message: Merged from 5.1 to 5.5 ------------------------------------------------------------ revno: 2661.812.1 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.1-59107 timestamp: Mon 2012-04-09 14:51:46 +0530 message: Bug #11766072 59107: MYSQLSLAP CRASHES IF STARTED WITH NO ARGUMENTS ON WINDOWS This bug is a duplicate of Bug #31173, which was pushed to the mysql-trunk 5.6 on 4th Aug, 2010. This is just a back-port of the fix ------------------------------------------------------------ revno: 3097.126.60 [merge] committer: Mayank Prasad <mayank.prasad@oracle.com> branch nick: emb_5.5 timestamp: Fri 2012-04-06 17:06:05 +0530 message: BUG#13738989 : 62136 : FAILED TO FETCH SELECT RESULT USING EMBEDDED MYSQLD Merge : 5.1->5.5 ------------------------------------------------------------ revno: 2661.800.48 committer: Mayank Prasad <mayank.prasad@oracle.com> branch nick: 5.1 timestamp: Fri 2012-04-06 17:03:13 +0530 message: BUG#13738989 : 62136 : FAILED TO FETCH SELECT RESULT USING EMBEDDED MYSQLD Background : In mysql-5.1, in a fix for bug#47485, code has been changed for mysql client (libmysql/libmysql.c) but corresponding code was not changed for embedded mysql. In that code change, after execution of a statement, mysql_stmt_store_result() checks for mysql->state to be MYSQL_STATUS_STATEMENT_GET_RESULT, instead of MYSQL_STATUS_GET_RESULT (earlier). Reason: In embedded mysql code, after execution, mysql->state was not set to MYSQL_STATUS_STATEMENT_GET_RESULT, so it was throwing OUT_OF_SYNC error. Fix: Fixed the code in libmysqld/lib_sql.cc to have mysql->state to be set to MYSQL_STATUS_STATEMENT_GET_RESULT after execution. ------------------------------------------------------------ revno: 3097.126.59 committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com> branch nick: mysql_5_5 timestamp: Wed 2012-04-04 11:13:42 +0530 message: Bug#12762885: 61713: MYSQL WILL NOT BIND TO "LOCALHOST" IF LOCALHOST IS BOTH IPV4/IPV6 ENABLED Analysis: ---------------------- The problem was that if a hostname resolves to more than one IP-address, the server (5.5) does not start due to an error. In 5.1 the server used to take some IP-address and start. It's a regression and should be fixed. 5.5 supports IPv6, while 5.1 does not. However, that should not prevent the server from start -- if a hostname has both IPv4 and IPv6 addresses, the server should choose some IPv4-address and start. It's been decided to prefer IPv4-address to be backward compatible with 5.1. Another problem was that the 5.6 server did not report proper error message when the specified hostname could not be resolved. So, the code has been changed to report proper error message. Testing ================================ 5.5 ============================= invalid hostname (localhos): => Following error message reported. 120308 15:52:09 [ERROR] Can't start server: cannot resolve hostname! 120308 15:52:09 [ERROR] Aborting invalid ip_address: => Following error message reported. 120308 15:56:06 [Note] Server hostname (bind-address): '123.123.123.123'; port: 3306 120308 15:56:06 [Note] - '123.123.123.123' resolves to '123.123.123.123'; 120308 15:56:06 [Note] Server socket created on IP: '123.123.123.123'. 120308 15:56:06 [ERROR] Can't start server: Bind on TCP/IP port: Cannot assign requested address Only ipv4 host configured: => Following message logged 120308 16:02:50 [Note] Server hostname (bind-address): 'localhost'; port: 3306 120308 16:02:50 [Note] - 'localhost' resolves to '127.0.0.1'; 120308 16:02:50 [Note] Server socket created on IP: '127.0.0.1' Only ipv6 host configured: => Following message logged 120308 16:04:03 [Note] Server hostname (bind-address): 'localhost'; port: 3306 120308 16:04:03 [Note] - 'localhost' resolves to '::1'; 120308 16:04:03 [Note] Server socket created on IP: '::1'. ipv4 and ipv6 host configured: => Following message logged 120308 16:05:02 [Note] Server hostname (bind-address): 'localhost'; port: 3306 120308 16:05:02 [Note] - 'localhost' resolves to '::1'; 120308 16:05:02 [Note] - 'localhost' resolves to '127.0.0.1'; 120308 16:05:02 [Note] Server socket created on IP: '127.0.0.1'. => Non localhost address 120308 16:08:20 [Note] Server hostname (bind-address): 'mysql_addr'; port: 3306 120308 16:08:20 [Note] - 'mysql_addr' resolves to '10.178.58.216'; 120308 16:08:20 [Note] - 'mysql_addr' resolves to 'fe80::120b:a9ff:fe69:59ec'; 120308 16:08:20 [Note] Server socket created on IP: '10.178.58.216'. More than one entry for ipv4 and ipv6 address: => Following message logged 120308 16:06:19 [Note] Server hostname (bind-address): 'localhost'; port: 3306 120308 16:06:19 [Note] - 'localhost' resolves to '::1'; 120308 16:06:19 [Note] - 'localhost' resolves to '::1'; 120308 16:06:19 [Note] - 'localhost' resolves to '127.0.0.1'; 120308 16:06:19 [Note] - 'localhost' resolves to '127.0.0.1'; 120308 16:06:19 [Note] Server socket created on IP: '127.0.0.1'. ------------------------------------------------------------ revno: 3097.126.58 committer: Inaam Rana <inaam.rana@oracle.com> branch nick: mysql-5.5 timestamp: Tue 2012-04-03 09:45:10 -0400 message: Fix Sun Studio compiler warnings due to extra ',' introduced in rev_id: inaam.rana@oracle.com-20120326134501-23554a8vhjg0wqbm ------------------------------------------------------------ revno: 3097.126.57 committer: Rohit Kalhans <rohit.kalhans@oracle.com> branch nick: mysql-5.5_b11765650 timestamp: Tue 2012-04-03 00:35:43 +0530 message: BUG#11765650 Follow-up patch for Valgrind failures on PB2. ------------------------------------------------------------ revno: 3097.126.56 committer: Rohit Kalhans <rohit.kalhans@oracle.com> branch nick: mysql-5.5_b11765650 timestamp: Fri 2012-03-30 18:35:53 +0530 message: BUG#11765650 - 58637: MARK UPDATES THAT DEPEND ON ORDER OF TWO KEYS UNSAFE Description: When the table has more than one unique or primary key, INSERT... ON DUP KEY UPDATE statement is sensitive to the order in which the storage engines checks the keys. Depending on this order, the storage engine may determine different rows to mysql, and hence mysql can update different rows on master and slave. Solution: We mark INSERT...ON DUP KEY UPDATE on a table with more than on unique key as unsafe therefore the event will be logged in row format if it is available (ROW/MIXED). If only STATEMENT format is available, a warning will be thrown. ------------------------------------------------------------ revno: 3097.126.55 committer: Hery Ramilison <hery.ramilison@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-03-29 20:29:14 +0200 message: Starting 5.5.23 build ------------------------------------------------------------ revno: 3097.126.54 tags: mysql-5.5.23, clone-5.5.23-build committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.5 timestamp: Thu 2012-03-29 15:07:54 +0200 message: Patch for Bug#13805127: Stored program cache produces wrong result in same THD. Background: - as described in MySQL Internals Prepared Stored (http://forge.mysql.com/wiki/MySQL_Internals_Prepared_Stored), the Optimizer sometimes does destructive changes to the parsed LEX-object (Item-tree), which makes it impossible to re-use that tree for PS/SP re-execution. - in order to be able to re-use the Item-tree, the destructive changes are remembered and rolled back after the statement execution. The problem, discovered by this bug, was that the objects representing GROUP-BY clause did not restored after query execution. So, the GROUP-BY part of the statement could not be properly re-initialized for re-execution after destructive changes. Those objects do not take part in the Item-tree, so they can not be saved using the approach for Item-tree. The fix is as follows: - introduce a new array in st_select_lex to store the original ORDER pointers, representing the GROUP-BY clause; - Initialize this array in fix_prepare_information(). - restore the list of GROUP-BY items in reinit_stmt_before_use(). |