|
------------------------------------------------------------
revno: 3953 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: release timestamp: Tue 2012-08-28 16:13:03 +0200 message: Bug#14549809 LINKING PROBLEM IN 5.5.28 BUILDS WITH THREADPOOL PLUGIN The use of Thread_iterator did not work on windows (linking problems). Solution: Change the interface between the thread_pool and the server to only use simple free functions. This patch is for 5.5 only (mimicks similar solution in 5.6) ------------------------------------------------------------ revno: 3952 [merge] tags: clone-5.5.28-build committer: Martin Hansson <martin.hansson@oracle.com> branch nick: mysql-5.5-push timestamp: Fri 2012-08-24 11:56:14 +0200 message: Bug#14498355: Merge ------------------------------------------------------------ revno: 3949.1.1 committer: Martin Hansson <martin.hansson@oracle.com> branch nick: mysql-5.5 timestamp: Fri 2012-08-24 10:17:08 +0200 message: Bug#14498355: DEPRECATION WARNINGS SHOULD NOT CONTAIN MYSQL VERSION NUMBERS If a system variable was declared as deprecated without mention of an alternative, the message would look funny, e.g. for @@delayed_insert_limit: Warning 1287 '@@delayed_insert_limit' is deprecated and will be removed in MySQL . The message was meant to display the version number, but it's not possible to give one when declaring a system variable. The fix does two things: 1) The definition of the message ER_WARN_DEPRECATED_SYNTAX_NO_REPLACEMENT is changed so that it does not display a version number. I.e. in English the message now reads: Warning 1287 The syntax '@@delayed_insert_limit' is deprecated and will be removed in a future version. 2) The message ER_WARN_DEPRECATED_SYNTAX_WITH_VER is discontinued in favor of ER_WARN_DEPRECATED_SYNTAX for system variables. This change was already done in versions 5.6 and above as part of wl#5265. This part is simply back-ported from the worklog. ------------------------------------------------------------ revno: 3951 committer: Ashish Agarwal<ashish.y.agarwal@oracle.com> branch nick: bug14363985 timestamp: Fri 2012-08-24 14:55:47 +0530 message: Bug#14363985: MYSQLD CRASHED WHEN DISABL AND ENABLE AUDI PLUGIN WHEN DDL OPERATION HAPPENING PROBLEM: While unloading the plugin, state is not checked before it is to be reaped. This can lead to simultaneous free of plugin memory by more than one thread. Multiple deallocation leads to server crash. In the present bug two threads deallocate the alog_log plugin. SOLUTION: A check is added to ensure that only one thread is unloading the plugin. NOTE: No mtr test is added as it requires multiple threads to access critical section. debug_sync cannot be used in the current senario because we dont have access to thread pointer in some of the plugin functions. IMHO no test case in the current time frame. ------------------------------------------------------------ revno: 3950 committer: Marc Alff <marc.alff@oracle.com> branch nick: mysql-5.5-cleanup timestamp: Fri 2012-08-24 10:01:59 +0200 message: Bug#13417440 : 63340: ARCHIVE FILE IO NOT INSTRUMENTED WARNING This patch is for mysql-5.5 only, to be null-merged to mysql-5.6 and mysql-trunk. This is a partial rollback of the file io instrumentation, removing the instrumentation for mysql_file_stat in the archive engine. See the bug comments for details. ------------------------------------------------------------ revno: 3949 committer: Gopal Shankar <gopal.shankar@oracle.com> branch nick: sf_mysql-5.5 timestamp: Fri 2012-08-24 09:51:42 +0530 message: Bug#14364558 ASSERT `TABLE_LIST->PRELOCKING_PLACEHOLDER==FALSE' FAILED IN CHECK_LOCK_AND_ST Problem: -------- lock_tables() is supposed to invoke check_lock_and_start_stmt() for TABLE_LIST which are directly used by top level statement. TABLE_LIST->prelocking_placeholder is set only for TABLE_LIST which are used indirectly by stored programs invoked by top level statement. Hence check_lock_and_start_stmt() should have TABLE_LIST->prelocking_placeholder==false always, but it is observed that this assert fails. The failure is found during RQG test rqg_signal_resignal. Analysis: --------- open_tables() invokes open_and_process_routines() where it finds all the TABLE_LIST that belong to the routine and adds it to thd->lex->query_tables. During this process if the open_and_process_routines() fail for some reason, we are supposed to chop-off all the TABLE_LIST found during calls to open_and_process_routines(). But, in practice this is not happening. thd->lex->query_tables_own_last is supposed to point to a node in thd->lex->query_tables, which would be a first TABLE_LIST used indirectly by stored programs invoked by top level statement. This is found to be not-set correctly when we plan to chop-off TABLE_LIST's, when open_and_process_routines() failed. close_tables_for_reopen() does chop-off all the TABLE_LIST added after thd->lex->query_table_own_last. This is invoked upon error in open_and_process_routines(). This call would not work as expected as thd->lex->query_tables_own_last is not set, or is not set to correctly. Further, when open_tables() restarts the process of finding TABLE_LIST belonging to stored programs, and as the thd->lex->query_tables_own_last points to in-correct node, there is possibility of new iteration setting the thd->lex->query_tables_own_last past some old nodes that belong to stored programs, added earlier and not removed. Later when open_tables() completes, lock_tables() ends up invoking check_lock_and_start_stmt() for TABLE_LIST which belong to stored programs, which is not expected behavior and hence we hit the assert TABLE_LIST->prelocking_placeholder==false. Due to above behavior, if a user application tries to execute a SQL statement which invokes some stored function and if the lock grant on stored function fails due to a deadlock, then mysqld crashes. Fix: ---- open_tables() remembers save_query_tables_last which points to thd-lex->query_tables_last before calls to open_and_process_routines(). If there is no known thd->lex->query_tables_own_last set, we are now setting thd->lex->query_tables_own_last to save_query_tables_last. This will make sure that the call to close_tables_for_reopen() will chop-off the list correctly, in other words we now remove all the nodes added to thd->lex->query_tables, by previous calls to open_and_process_routines(). Further, it is found that the problem exists starting from 5.5, due to a code refactoring effort related to open_tables(). Hence, the fix will be pushed in 5.5, 5.6 and trunk. ------------------------------------------------------------ revno: 3948 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.5-bug65948 timestamp: Thu 2012-08-23 16:29:41 +0200 message: Bug#14463247 ORDER BY SUBQUERY REFERENCING OUTER ALIAS FAILS Documentation for class Item_outer_ref was wrong: (*ref) may point to Item_field as well (see e.g. Item_outer_ref::fix_fields) So this casting in get_store_key() was wrong: (*(Item_ref**)((Item_ref*)keyuse->val)->ref)->ref_type() ------------------------------------------------------------ revno: 3947 committer: Georgi Kodinov <Georgi.Kodinov@Oracle.com> branch nick: mysql-5.5-commercial timestamp: Fri 2012-08-17 18:02:44 +0300 message: Bug #14399795 : ISSUES RELATED TO SETTING AUDIT_LOG_STRATEGY DURING SERVER STARTUP The options parser now correctly checks for ambiguous prefixes in enumerated variables and emits an error when the value supplied is ambiguous. No test added since mysql-test-run.pl can't handle server startup failures as an expected state. ------------------------------------------------------------ revno: 3946 [merge] committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.5 timestamp: Tue 2012-08-21 10:59:11 +0300 message: Merge mysql-5.1 to mysql-5.5. ------------------------------------------------------------ revno: 2661.810.76 committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.1 timestamp: Tue 2012-08-21 10:47:17 +0300 message: Fix regression from Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG HEURISTICS FOR COMPRESSED PAGE SIZE The fix of Bug#12845774 was supposed to skip known-to-fail btr_cur_optimistic_insert() calls. There was only one such call, in btr_cur_pessimistic_update(). All other callers of btr_cur_pessimistic_insert() would release and reacquire the B-tree page latch before attempting the pessimistic insert. This would allow other threads to restructure the B-tree, allowing (and requiring) the insert to succeed as an optimistic (single-page) operation. Failure to attempt an optimistic insert before a pessimistic one would trigger an attempt to split an empty page. rb:1234 approved by Sunny Bains ------------------------------------------------------------ revno: 3945 [merge] committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: topush-5.5 timestamp: Mon 2012-08-20 12:44:40 +0200 message: merge ------------------------------------------------------------ revno: 2661.810.75 committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: topush-5.1 timestamp: Mon 2012-08-20 12:39:36 +0200 message: Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY pre-push fix, removed unused variable. ------------------------------------------------------------ revno: 3944 [merge] committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: topush-5.5 timestamp: Mon 2012-08-20 11:20:00 +0200 message: merge ------------------------------------------------------------ revno: 2661.810.74 [merge] committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: topush-5.1 timestamp: Mon 2012-08-20 11:18:17 +0200 message: merge ------------------------------------------------------------ revno: 3943 [merge] committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: topush-5.5 timestamp: Mon 2012-08-20 11:19:02 +0200 message: merge ------------------------------------------------------------ revno: 3940.1.2 [merge] committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: b13025132-55 timestamp: Mon 2012-08-20 09:55:54 +0200 message: merge ------------------------------------------------------------ revno: 2661.826.2 committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: b13025132-51 timestamp: Fri 2012-08-17 14:25:32 +0200 message: Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY Additional patch to remove the part_id -> ref_buffer offset. The partitioning id and the associate record buffer can be found without having to calculate it. By initializing it for each used partition, and then reuse the key-buffer from the queue, it is not needed to have such map. ------------------------------------------------------------ revno: 3940.1.1 [merge] committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: b13025132-55 timestamp: Wed 2012-08-15 14:56:55 +0200 message: manual merge 5.1->5.5 ------------------------------------------------------------ revno: 2661.826.1 committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: b13025132-51 timestamp: Wed 2012-08-15 14:31:26 +0200 message: Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY The buffer for the current read row from each partition (m_ordered_rec_buffer) used for sorted reads was allocated on open and freed when the ha_partition handler was closed or destroyed. For tables with many partitions and big records this could take up too much valuable memory. Solution is to only allocate the memory when it is needed and free it when nolonger needed. I.e. allocate it in index_init and free it in index_end (and to handle failures also free it on reset, close etc.) Also only allocating needed memory, according to partitioning pruning. Manually tested that it does not use as much memory and releases it after queries. ------------------------------------------------------------ revno: 3942 [merge] committer: Alexander Barkov <alexander.barkov@oracle.com> branch nick: mysql-5.5 timestamp: Fri 2012-08-17 13:18:56 +0400 message: Merging from 5.5 ------------------------------------------------------------ revno: 2661.810.73 committer: Alexander Barkov <alexander.barkov@oracle.com> branch nick: mysql-5.1 timestamp: Fri 2012-08-17 13:14:04 +0400 message: Backporting Bug 14100466 from 5.6. ------------------------------------------------------------ revno: 3941 [merge] committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-08-16 18:47:26 +0300 message: Merge mysql-5.1 to mysql-5.5. ------------------------------------------------------------ revno: 2661.810.72 committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-08-16 17:45:39 +0300 message: Bug#12595091 POSSIBLY INVALID ASSERTION IN BTR_CUR_PESSIMISTIC_UPDATE() Facebook got a case where the page compresses really well so that btr_cur_optimistic_update() returns DB_UNDERFLOW, but when a record gets updated, the compression rate radically changes so that btr_cur_insert_if_possible() can not insert in place despite reorganizing/recompressing the page, leading to the assertion failing. rb:1220 approved by Sunny Bains ------------------------------------------------------------ revno: 2661.810.71 committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-08-16 17:37:52 +0300 message: Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG HEURISTICS FOR COMPRESSED PAGE SIZE This was submitted as MySQL Bug 61456 and a patch provided by Facebook. This patch follows the same idea, but instead of adding a parameter to btr_cur_pessimistic_insert(), we simply remove the btr_cur_optimistic_insert() call there and add it to the only caller that needs it. btr_cur_pessimistic_insert(): Do not try btr_cur_optimistic_insert(). btr_insert_on_non_leaf_level_func(): Invoke btr_cur_optimistic_insert() before invoking btr_cur_pessimistic_insert(). btr_cur_pessimistic_update(): Clarify in a comment why it is not necessary to invoke btr_cur_optimistic_insert(). btr_root_raise_and_insert(): Assert that the root page is not empty. This could happen if a pessimistic insert (involving a split or merge) is performed without first attempting an optimistic (intra-page) insert. rb:1219 approved by Sunny Bains ------------------------------------------------------------ revno: 2661.810.70 committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-08-16 17:31:23 +0300 message: Bug#13523839 ASSERTION FAILURES ON COMPRESSED INNODB TABLES btr_cur_optimistic_insert(): Remove a bogus assertion. The insert may fail after reorganizing the page. btr_cur_optimistic_update(): Do not attempt to reorganize compressed pages, because compression may fail after reorganization. page_copy_rec_list_start(): Use page_rec_get_nth() to restore to the ret_pos, which may also be the page infimum. rb:1221 ------------------------------------------------------------ revno: 3940 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: 5.5 timestamp: Tue 2012-08-14 15:13:30 +0530 message: Bug #12992993 MYSQLHOTCOPY FAILS IF VIEW EXISTS Problem description: mysqlhotcopy fails if a view presents in the database. Analysis: Before 5.5 'FLUSH TABLES <tbl_name> ... WITH READ LOCK' will able to get lock for all tables (i.e. base tables and view tables). In 5.5 onwards 'FLUSH TABLES <tbl_name> ... WITH READ LOCK' for 'view tables' will not work, because taking flush locks on view tables is not valid. Fix: Take flush lock for 'base tables' and read lock for 'view table' separately. Note: most of the patch has been backported from bug#13006947's patch ------------------------------------------------------------ revno: 3939 [merge] committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com> branch nick: Bug13596613_user_var_mysql-5.5 timestamp: Tue 2012-08-14 14:21:40 +0530 message: merge from 5.1 to 5.5 ------------------------------------------------------------ revno: 2661.810.69 committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com> branch nick: Bug13596613_user_var timestamp: Tue 2012-08-14 14:11:01 +0530 message: Bug#13596613:SHOW SLAVE STATUS GIVES WRONG OUTPUT WITH MASTER-MASTER AND USING SET USE Problem: ======= In a master-master set-up, a master can show a wrong 'SHOW SLAVE STATUS' output. Requirements: - master-master - log_slave_updates This is caused when using SET user-variables and then using it to perform writes. From then on the master that performed the insert will have a SHOW SLAVE STATUS that is wrong and it will never get updated until a write happens on the other master. On"Master A" the "exec_master_log_pos" is not getting updated. Analysis: ======== Slave receives a "User_var" event from the master and after applying the event, when "log_slave_updates" option is enabled the slave tries to write this applied event into its own binary log. At the time of writing this event the slave should use the "originating server-id". But in the above case the sever always logs the "user var events" by using its global server-id. Due to this in a "master-master" replication when the event comes back to the originating server the "User_var_event" doesn't get skipped. "User_var_events" are context based events and they always follow with a query event which marks their end of group. Due to the above mentioned problem with "User_var_event" logging the "User_var_event" never gets skipped where as its corresponding "query_event" gets skipped. Hence the "User_var" event always waits for the next "query event" and the "Exec_master_log_position" does not get updated properly. Fix: === `MYSQL_BIN_LOG::write' function is used to write events into binary log. Within this function a new object for "User_var_log_event" is created and this new object is used to write the "User_var" event in the binlog. "User var" event is inherited from "Log_event". This "Log_event" has different overloaded constructors. When a "THD" object is present "Log_event(thd,...)" constructor should be used to initialise the objects and in the absence of a valid "THD" object "Log_event()" minimal constructor should be used. In the above mentioned problem always default minimal constructor was used which is incorrect. This minimal constructor is replaced with "Log_event(thd,...)". ------------------------------------------------------------ revno: 3938 [merge] committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: topush-5.5 timestamp: Mon 2012-08-13 11:21:28 +0200 message: merge ------------------------------------------------------------ revno: 3936.1.1 committer: Mattias Jonsson <mattias.jonsson@oracle.com> branch nick: b14342883-55 timestamp: Thu 2012-08-09 12:51:37 +0200 message: Bug#14342883: SELECT QUERY RETURNS NOT ALL ROWS THAT ARE EXPECTED For non range/list partitioned tables (i.e. HASH/KEY): When prune_partitions finds a multi-range list (or in this test '<>') for a field of the partition index, even if it cannot make any use of the multi-range, it will continue with the next field of the partition index and use that for pruning (even if it the previous field could not be used). This results in partitions is pruned away, leaving partitions that only matches the last field in the partition index, and will exclude partitions which might match any previous fields. Fixed by skipping rest of partitioning key fields/parts if current key field/part could not be used. Also notice it is the order of the fields in the CREATE TABLE statement that triggers this bug, not the order of fields in primary/unique key or PARTITION BY KEY (). It must not be the last field in the partitioning expression that is not equal (or have a non single point range). I.e. the partitioning index is created with the same field order as in the CREATE TABLE. And for the bug to appear the last field must be a single point and some previous field must be a multi-point range. ------------------------------------------------------------ revno: 3937 [merge] committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: 5.5 timestamp: Sat 2012-08-11 15:52:11 +0530 message: Bug #13115401: -SSL-KEY VALUE IS NOT VALIDATED AND IT ALLOWS INSECURE CONNECTIONS IF SPE Merged from mysql-5.1 to mysql-5.5 ------------------------------------------------------------ revno: 2661.810.68 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: 5.1 timestamp: Sat 2012-08-11 15:43:04 +0530 message: Bug #13115401: -SSL-KEY VALUE IS NOT VALIDATED AND IT ALLOWS INSECURE CONNECTIONS IF SPE Problem description: -ssl-key value is not validated, you can assign any bogus text to --ssl-key and it is not verified that it exists, and more importantly, it allows the client to connect to mysqld. Fix: Added proper validations checks for --ssl-key. Note: 1) Documentation changes require for 5.1, 5.5, 5.6 and trunk in the sections listed below and the details are : http://dev.mysql.com/doc/refman/5.6/en/ssl-options.html#option_general_ssl and REQUIRE SSL section of http://dev.mysql.com/doc/refman/5.6/en/grant.html 2) Client having with option '--ssl', should able to get ssl connection. This will be implemented as part of separate fix in 5.6 and trunk. ------------------------------------------------------------ revno: 3936 [merge] committer: Sergey Glukhov <sergey.glukhov@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-08-09 15:50:29 +0400 message: 5.1 -> 5.5 merge ------------------------------------------------------------ revno: 2661.810.67 committer: Sergey Glukhov <sergey.glukhov@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-08-09 15:34:52 +0400 message: Bug #14409015 MEMORY LEAK WHEN REFERENCING OUTER FIELD IN HAVING When resolving outer fields, Item_field::fix_outer_fields() creates new Item_refs for each execution of a prepared statement, so these must be allocated in the runtime memroot. The memroot switching before resolving JOIN::having causes these to be allocated in the statement root, leaking memory for each PS execution. ------------------------------------------------------------ revno: 3935 [merge] committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-08-09 10:58:08 +0300 message: Merge mysql-5.5 to working copy. ------------------------------------------------------------ revno: 3933.1.1 committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: main-55 timestamp: Thu 2012-08-09 09:51:34 +0200 message: Small cmake syntax fix to fix to -Werror build breakage ------------------------------------------------------------ revno: 3934 [merge] committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-08-09 10:50:54 +0300 message: Null merge from mysql-5.1. ------------------------------------------------------------ revno: 2661.810.66 [merge] committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-08-09 10:48:25 +0300 message: Merge from mysql-5.1 to working copy. ------------------------------------------------------------ revno: 2661.825.1 [merge] committer: Sunanda Menon <sunanda.menon@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-08-09 08:50:43 +0200 message: Merge from mysql-5.1.65-release ------------------------------------------------------------ revno: 2661.824.1 [merge] tags: mysql-5.1.65 committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: mysql-5.1.65-release timestamp: Thu 2012-07-12 10:00:14 +0200 message: Merge unpushed changes from 5.1.64-release ------------------------------------------------------------ revno: 2661.823.4 committer: Kent Boortz <kent.boortz@oracle.com> branch nick: mysql-5.1.64-release timestamp: Tue 2012-06-26 16:30:15 +0200 message: Solve a linkage problem with "libmysqld" on several Solaris platforms: a multiple definition of 'THD::clear_error()' in (at least) libmysqld.a(lib_sql.o) and libmysqld.a(libfederated_a-ha_federated.o). Patch provided by Ramil Kalimullin. ------------------------------------------------------------ revno: 2661.823.3 committer: Joerg Bruehe <joerg.bruehe@oracle.com> branch nick: mysql-5.1.64-release timestamp: Thu 2012-06-21 16:26:50 +0200 message: Fixing wrong comment syntax (discovered by Kent) ------------------------------------------------------------ revno: 2661.823.2 committer: Kent Boortz <kent.boortz@oracle.com> branch nick: mysql-5.1.64-release timestamp: Wed 2012-06-20 13:10:13 +0200 message: Version for this release build is 5.1.64 ------------------------------------------------------------ revno: 2661.823.1 [merge] committer: Kent Boortz <kent.boortz@oracle.com> branch nick: mysql-5.1.64-release timestamp: Wed 2012-06-20 13:06:32 +0200 message: Merge ------------------------------------------------------------ revno: 3933 [merge] committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-08-09 10:06:59 +0300 message: Merge mysql-5.1 to mysql-5.5. ------------------------------------------------------------ revno: 2661.810.65 committer: Marko M?kel? <marko.makela@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-08-09 09:55:29 +0300 message: Bug#14399148 INNODB TABLES UNDER LOAD PRODUCE DUPLICATE COPIES OF ROWS IN QUERIES This bug was caused by an incorrect fix of Bug#13807811 BTR_PCUR_RESTORE_POSITION() CAN SKIP A RECORD There was nothing wrong with btr_pcur_restore_position(), but with the use of it in the table scan during index creation. rb:1206 approved by Jimmy Yang ------------------------------------------------------------ revno: 3932 [merge] committer: Rohit Kalhans <rohit.kalhans@oracle.com> branch nick: mysql-5.5-11757312 timestamp: Wed 2012-08-08 22:20:05 +0530 message: upmerge from mysql-5.1=>mysql-5.5 ------------------------------------------------------------ revno: 2661.810.64 committer: Rohit Kalhans <rohit.kalhans@oracle.com> branch nick: mysql-5.1-11757312 timestamp: Wed 2012-08-08 22:15:46 +0530 message: BUG#11757312: MYSQLBINLOG DOES NOT ACCEPT INPUT FROM STDIN WHEN STDIN IS A PIPE Problem: Mysqlbinlog does not accept the input from STDIN when STDIN is a pipe. This prevents the users from passing the input file through a shell pipe. Background: The my_seek() function does not check if the file descriptor passed to it is regular (seekable) file. The check_header() function in mysqlbinlog calls the my_b_seek() unconditionally and it fails when the underlying file is a PIPE. Resolution: We resolve this problem by checking if the underlying file is a regular file by using my_fstat() before calling my_b_seek(). If the underlying file is not seekable we skip the call to my_b_seek() in check_header(). ------------------------------------------------------------ revno: 3931 [merge] committer: Nirbhay Choubey <nirbhay.choubey@oracle.com> branch nick: 5.5 timestamp: Tue 2012-08-07 19:07:13 +0530 message: Merge of patch for Bug#13928675 from mysql-5.1. ------------------------------------------------------------ revno: 2661.810.63 committer: Nirbhay Choubey <nirbhay.choubey@oracle.com> branch nick: 5.1 timestamp: Tue 2012-08-07 18:58:19 +0530 message: Bug#13928675 MYSQL CLIENT COPYRIGHT NOTICE MUST SHOW 2012 INSTEAD OF 2011 * Added a new macro to hold the current year : COPYRIGHT_NOTICE_CURRENT_YEAR * Modified ORACLE_WELCOME_COPYRIGHT_NOTICE macro to take the initial year as parameter and pick current year from the above mentioned macro. ------------------------------------------------------------ revno: 3930 [merge] committer: Harin Vadodaria<harin.vadodaria@oracle.com> branch nick: 55-bug14068244 timestamp: Tue 2012-08-07 16:27:40 +0530 message: Bug#14068244: INCOMPATIBILITY BETWEEN LIBMYSQLCLIENT/LIBMYSQLCLIENT_R AND LIBCRYPTO Description: Merge from 5.1 to 5.5 ------------------------------------------------------------ revno: 2661.810.62 committer: Harin Vadodaria<harin.vadodaria@oracle.com> branch nick: 51-bug14068244 timestamp: Tue 2012-08-07 16:23:53 +0530 message: Bug#14068244: INCOMPATIBILITY BETWEEN LIBMYSQLCLIENT/LIBMYSQLCLIENT_R AND LIBCRYPTO Problem: libmysqlclient_r exports symbols from yaSSL library which conflict with openSSL symbols. This issue is related to symbols used by CURL library and are defined in taocrypt. Taocrypt has dummy implementation of these functions. Due to this when a program which uses libcurl library functions is compiled using libmysqlclient_r and libcurl, it hits segmentation fault in execution phase. Solution: MySQL should not be exporting such symbols. However, these functions are not used by MySQL code at all. So avoid compiling them in the first place. ------------------------------------------------------------ revno: 3929 committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com> branch nick: mysql-5.5 timestamp: Tue 2012-08-07 11:48:36 +0530 message: Bug#13058122 - DML, LOCK/UNLOCK TABLES AND SELECT LEAD TO FOREVER MDL LOCK Analysis: ---------- While granting MDL lock for the lock requests in wait queue, first the lock is granted to the high priority lock types and then to the low priority lock types. MDL Priority Matrix, +-------------+----+---+---+---+----+-----+ | Locks | | | | | | | | has Priority| | | | | | | | over ---> | S | SR| SW| SU| SNW| SNRW| +-------------+----+---+---+---+----+-----+ | X | + | + | + | + | + | + | +-------------|----|---|---|---|----|-----| | SNRW | - | + | + | - | - | - | +-------------|----|---|---|---|----|-----| | SNW | - | - | + | - | - | - | +-------------+----+---+---+---+----+-----+ Here '+' means, Lock priority is higher. '-' means, Has same priority In the scenario where, *. Lock wait queue has requests of type S/SR/SW/SU. *. And locks of high priority X/SNRW/SNW are requested continuously. In this case, while granting lock, always first high priority lock requests(X/SNRW/SNW) are considered. Low priority locks(S/SR/SW/SU) will not get chance and they will wait forever. In the scenario for which this bug is reported, application executed many LOCK TABLES ... WRITE statements concurrently. These statements request SNRW lock. Also there were some connections trying to execute DML statements requesting SR lock. Since SNRW lock request has higher priority (and as they were too many waiting SNRW requests) lock is always granted to it. So, lock request SR will wait forever, resulting in DML starvation. How is this handled in 5.1? --------------------------- Even in 5.1 we have low priority lock starvation issue. But, in 5.1 thread locking, system variable "max_write_lock_count" can be configured to grant some pending read lock requests. After "max_write_lock_count" of write lock grants all the low priority locks are granted. Why this issue is seen in 5.5/trunk? --------------------------------- In 5.5/trunk MDL locking, "max_write_lock_count" system variable exists but not used in MDL, only thread lock uses it. So no effect of "max_write_lock_count" in MDL locking. This means that starvation of metadata locks is possible even if max_write_lock_count is used. Looks like, customer was using "max_write_lock_count" in 5.1 and when upgraded to 5.5, starvation is seen because of not having effect of "max_write_lock_count" in MDL. Fix: ---------- As a fix, support for max_write_lock_count is added to MDL. To maintain write lock counter per MDL_lock object, new member "m_hog_lock_count" is added in MDL_lock. And following logic is added to increment the counter in function reschedule_waiters, (reschedule_waiters function is called while thread is releasing the lock) - After granting lock request from the wait queue. - Check if there are any S/SR/SU/SW exists in the wait queue - If yes then increment the "m_hog_lock_count" And following logic is added in the same function to handle pending S/SU/SR/SW locks - Before granting locks - Check if max_write_lock_count <= m_hog_lock_count - If Yes, then try to grant S/SR/SW/SU locks. (Since all of these has same priority, all locks are granted together. But some lock grant may fail because of grant incompatibility) - Reset m_hog_lock_count if there no low priority lock requests in wait queue. - return Note: -------------------------- In the lock priority matrix explained above, though X has priority over the SNW and SNRW. X locks is taken mostly for RENAME, TRUNCATE, CREATE ... operations. So lock type X may not be requested in loop continuously in real world applications, as compared to other lock request types. So, lock request of type SNW and SNRW are not starved. So, we can grant all S/SR/SU/SW in one shot, without considering SNW & SNRW lock request starvation. ALTER table operations take SU lock first and then upgrade to SNW if required. All S, SR, SW, SU have same lock priority. So while granting SU, request of types SR, SW, S are also granted in one shot. So, lock request of type SU->SNW in loop will not make other low priority lock request to starve. But, when there is request for lock of type SNRW, lock requests of lower priority types are not granted. And if SNRW is requested in loop continuously then all S, SR, SW, SU are starved. This patch addresses the latter scenario. When we have S/SR/SW/SU in wait queue and if there are - Continuous SNRW lock requests - OR one or more X and Continuous SNRW lock requests. - OR one SNW and Continuous SNRW lock requests. - OR one SNW, one or more X and continuous SNRW lock requests. in wait queue then, S/SR/SW/SU lock request are starved. ------------------------------------------------------------ revno: 3928 [merge] committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com> branch nick: mysql-5.5 timestamp: Mon 2012-08-06 10:40:03 +0530 message: Merge from 5.1 to 5.5 ------------------------------------------------------------ revno: 2661.810.61 committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com> branch nick: mysql-5.1 timestamp: Sun 2012-08-05 16:29:28 +0530 message: Bug #14099846: EXPORT_SET CRASHES DUE TO OVERALLOCATION OF MEMORY Backport the fix from 5.6 to 5.1 Base bug number : 11765562 ------------------------------------------------------------ revno: 3927 author: hery.ramilison@oracle.com committer: Hery Ramilison <hery.ramilison@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-08-02 21:09:42 +0200 message: Merge from mysql-5.5.27-release ------------------------------------------------------------ revno: 3926 [merge] committer: Joerg Bruehe <joerg.bruehe@oracle.com> branch nick: mysql-5.5 timestamp: Tue 2012-07-31 20:45:36 +0200 message: INSTALL-BINARY placeholder (upmerge from 5.1): change invalid URLs (request from Kristofer) ------------------------------------------------------------ revno: 2661.810.60 committer: Joerg Bruehe <joerg.bruehe@oracle.com> branch nick: mysql-5.1 timestamp: Tue 2012-07-31 20:41:46 +0200 message: INSTALL-BINARY placeholder: change invalid URLs (request from Kristofer) ------------------------------------------------------------ revno: 3925 [merge] committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.5-merge timestamp: Fri 2012-07-27 09:19:35 +0200 message: merge 5.1 => 5.5 ------------------------------------------------------------ revno: 2661.810.59 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.1 timestamp: Fri 2012-07-27 09:13:10 +0200 message: Bug#14111180 HANDLE_FATAL_SIGNAL IN PTR_COMPARE_1 / QUEUE_INSERT Space available for merging was calculated incorrectly. ------------------------------------------------------------ revno: 3924 [merge] committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.5-59107-new timestamp: Fri 2012-07-27 12:12:15 +0530 message: Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Null merge from 5.1 to 5.5 ------------------------------------------------------------ revno: 2661.810.58 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.1-59107 timestamp: Fri 2012-07-27 12:05:37 +0530 message: Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Fixed the missing of federated/include folder at the time of preparing package distribution, issue happens only in 5.1 ------------------------------------------------------------ revno: 3923 [merge] committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com> branch nick: mysql_5_5 timestamp: Thu 2012-07-26 23:53:45 +0530 message: Merge from 5.1 to 5.5 ------------------------------------------------------------ revno: 2661.810.57 committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com> branch nick: mysql_5_1 timestamp: Thu 2012-07-26 23:44:43 +0530 message: BUG#13868860 - LIMIT '5' IS EXECUTED WITHOUT ERROR WHEN '5' IS PLACE HOLDER AND USE SERVER-SIDE Analysis: LIMIT always takes nonnegative integer constant values. http://dev.mysql.com/doc/refman/5.6/en/select.html So parsing of value '5' for LIMIT in SELECT fails. But, within prepared statement, LIMIT parameters can be specified using '?' markers. Value for the parameter can be supplied while executing the prepared statement. Passing string values, float or double value for LIMIT works well from CLI. Because, while setting the value for the parameters from the variable list (added using SET), if the value is for parameter LIMIT then its converted to integer value. But, when prepared statement is executed from the other interfaces as J connectors, or C applications etc. The value for the parameters are sent to the server with execute command. Each item in log has value and the data TYPE. So, While setting parameter value from this log, value is set to all the parameters with the same data type as passed. But here logic to convert value to integer type if its for LIMIT parameter is missing. Because of this,string '5' is set to LIMIT. And the same is logged into the binlog file too. Fix: When executing prepared statement having parameter for CLI it worked fine, as the value set for the parameter is converted to integer. And this failed in other interfaces as J connector,C Applications etc as this conversion is missing. So, as a fix added check while setting value for the parameters. If the parameter is for LIMIT value then its converted to integer value. ------------------------------------------------------------ revno: 3922 [merge] committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.5-59107-new timestamp: Thu 2012-07-26 23:27:01 +0530 message: Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Merged pb2 test failure fix from mysql-5.1 to mysql-5.5 ------------------------------------------------------------ revno: 2661.810.56 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.1-59107 timestamp: Thu 2012-07-26 23:23:04 +0530 message: Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Fix for pb2 test failure. ------------------------------------------------------------ revno: 3921 [merge] committer: Nirbhay Choubey <nirbhay.choubey@oracle.com> branch nick: 5.5 timestamp: Thu 2012-07-26 21:59:05 +0530 message: Merge of patch for Bug#13741677 from mysql-5.1. ------------------------------------------------------------ revno: 2661.810.55 committer: Nirbhay Choubey <nirbhay.choubey@oracle.com> branch nick: B13741677-5.1 timestamp: Thu 2012-07-26 21:47:03 +0530 message: Bug#13741677 MYSQL_SECURE_INSTALLATION DOES NOT WORK + SAVES ROOT PASSWORD TO DISK! The secure installation scripts connect to the server by storing the password in a temporary option file. Now, if the script gets killed or fails for some reason, the removal of the option file may not take place. This patch introduces following enhancements : * (.sh) Made sure that cleanup happens at every call to 'exit 1'. This is performed implicitly by END{} in pl.in. * (.pl.in) Added a warning in case unlink fails to delete the option/query files. * (.sh/.pl.in) Added more signals to the signal handler list. SIG# 1, 3, 6, 15 ------------------------------------------------------------ revno: 3920 [merge] committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.5-merge timestamp: Thu 2012-07-26 15:06:43 +0200 message: merge 5.1 => 5.5 ------------------------------------------------------------ revno: 2661.810.54 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.1 timestamp: Thu 2012-07-26 15:05:24 +0200 message: Backport of Bug#14171740 65562: STRING::SHRINK SHOULD BE A NO-OP WHEN ALLOCED=0 ------------------------------------------------------------ revno: 3919 [merge] committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.5-59107-new timestamp: Thu 2012-07-26 15:29:19 +0530 message: Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Merged from mysql-5.1 to mysql-5.5 ------------------------------------------------------------ revno: 2661.810.53 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.1-59107 timestamp: Thu 2012-07-26 15:09:22 +0530 message: Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Problem description: Table 't' created with two colums having compound index on both the columns under innodb/myisam engine at remote machine. In the local machine same table is created undet the federated engine. A select having where clause with along 'AND' operation gives wrong results on local machine. Analysis: The given query at federated engine is wrongly transformed by federated::create_where_from_key() function and the same was sent to the remote machine. Hence the local machine is showing wrong results. Given query "select c1 from t where c1 <= 2 and c2 = 1;" Query transformed, after ha_federated::create_where_from_key() function is: SELECT `c1`, `c2` FROM `t` WHERE (`c1` IS NOT NULL ) AND ( (`c1` >= 2) AND (`c2` <= 1) ) and the same sent to real_query(). In the above the '<=' and '=' conditions were transformed to '>=' and '<=' respectively. ha_federated::create_where_from_key() function behaving as below: The key_range is having both the start_key and end_key. The start_key is used to get "(`c1` IS NOT NULL )" part of the where clause, this transformation is correct. The end_key is used to get "( (`c1` >= 2) AND (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') are changed as wrong conditions('>=' and '<='). The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, flag = HA_READ_AFTER_KEY} The store_length is having value '5'. Based on store_length and length values the condition values is applied in HA_READ_AFTER_KEY switch case. The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, here the '>=' is getting added as a condition instead of '<='. Fix: Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in the if condition. ------------------------------------------------------------ revno: 3918 committer: Thayumanavar <thayumanavar.x.sachithanantha@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2012-07-25 16:24:18 +0530 message: Bug#13699303 - THREAD POOL PLUGIN IGNORES TIMEOUT. PROBLEM: mysql provides a feature where in a session which is idle for a period specified by the wait_timeout variable (whose value is in seconds), the session is closed This feature is not present when we use thread pool. FIX: This patch implements the interface functions which is required to implement the wait_timeout functionality in the thread pool plugin. ------------------------------------------------------------ revno: 3917 committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com> branch nick: Bug13961678 timestamp: Wed 2012-07-25 14:56:37 +0530 message: Follow up patch for BUG#13961678. Fixing compilation warning given below. "warning: integer constant is too large for 'long' type" ------------------------------------------------------------ revno: 3916 [merge] committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2012-07-25 13:53:01 +0530 message: Null merge from mysql-5.1 to mysql-5.5. ------------------------------------------------------------ revno: 2661.810.52 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.1 timestamp: Wed 2012-07-25 13:51:39 +0530 message: Bug #13113026 INFORMATION_SCHEMA.INNODB_BUFFER_PAGE_LRUFROM 5.6 BACKPORT Backporting the WL#5716, "Information schema table for InnoDB buffer pool information". Backporting revisions 2876.244.113, 2876.244.102 from mysql-trunk. rb://1175 approved by Jimmy Yang. ------------------------------------------------------------ revno: 3915 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2012-07-25 10:48:16 +0530 message: Bug #13113026 INFORMATION_SCHEMA.INNODB_BUFFER_PAGE_LRUFROM 5.6 BACKPORT Backporting the WL#5716, "Information schema table for InnoDB buffer pool information". Backporting revisions 2876.244.113, 2876.244.102 from mysql-trunk. rb://1177 approved by Jimmy Yang. ------------------------------------------------------------ revno: 3914 committer: Harin Vadodaria<harin.vadodaria@oracle.com> branch nick: 55_new timestamp: Tue 2012-07-24 18:45:58 +0530 message: Bug#13904906: YASSL PRE-AUTH CRASH WITH 5.1.62, 5.5.22 Problem: Valgrind reports errors when an invalid certificate is used on the client. Solution: Updated yaSSL to version 2.2.2. ------------------------------------------------------------ revno: 3913 committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com> branch nick: Bug13961678 timestamp: Tue 2012-07-24 16:26:16 +0530 message: Bug#13961678:MULTI-STATEMENT TRANSACTION REQUIRED MORE THAN 'MAX_BINLOG_CACHE_SIZE' ERROR Problem: ======= MySQL returns following error in win64. "ERROR 1197 (HY000): Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again" when user tries to load >4G file even if max_binlog_cache_size set to maximum value. On Linux everything works fine. Analysis: ======== The `max_binlog_cache_size' variable is of type `ulonglong'. This value is set to `ULONGLONG_MAX' at the time of server start up. The above value is stored in an intermediate variable named `saved_max_binlog_cache_size' which is of type `ulong'. In visual c++ complier the `ulong' type is of 4bytes in size and hence the value is getting truncated to '4GB' and the cache is not able to grow beyond 4GB size. The same limitation is observed with "max_binlog_stmt_cache_size" as well. Similar fix has been applied. Fix: === As part of fix the type "ulong" is replaced with "my_off_t" which is of type "ulonglong". ------------------------------------------------------------ revno: 3912 committer: Joerg Bruehe <joerg.bruehe@oracle.com> branch nick: bug14318456-5.5 timestamp: Tue 2012-07-24 12:32:14 +0200 message: Fix bug#14318456 SPEC FILE DOES NOT RUN THE TEST SUITE DURING RPM BUILD Add a macro "runselftest" to the spec file for RPM builds. If its value is 1 (the default), the test suite will be run during the RPM build. To prevent that, add this to the rpmbuild command line: --define "runselftest 0" Failures of the test suite will NOT make the RPM build fail! ------------------------------------------------------------ revno: 3911 [merge] committer: Alexander Barkov <alexander.barkov@oracle.com> branch nick: mysql-5.5 timestamp: Tue 2012-07-24 09:29:16 +0400 message: Merging from 5.1 ------------------------------------------------------------ revno: 2661.810.51 committer: Alexander Barkov <alexander.barkov@oracle.com> branch nick: mysql-5.1 timestamp: Tue 2012-07-24 09:27:00 +0400 message: Fixing wrong copyright. Index.xml was modified in 2005, while the copyright notice still mentioned 2003. ------------------------------------------------------------ revno: 3910 [merge] committer: Ashish Agarwal<ashish.y.agarwal@oracle.com> branch nick: mysql-5.5 timestamp: Mon 2012-07-23 14:05:13 +0530 message: BUG#13555854: CHECK AND REPAIR TABLE SHOULD BE MORE ROBUST [1] ISSUE: Incorrect key file. Key file is corrupted, Reading incorrect key information (keyseg) from index file. Key definition in .MYI and .FRM file differs. Starting pointer to read the keyseg information is changed to a value greater than the pack_reclength. Memcpy tries to read keyseg information from unallocated memory which causes the crash. SOLUTION: One more check added to compare the the key definition in .MYI and .FRM file. If the definition differ, server produces an error. ------------------------------------------------------------ revno: 3872.1.1 committer: Ashish Agarwal<ashish.y.agarwal@oracle.com> branch nick: mysql-5.5 timestamp: Mon 2012-07-02 15:20:23 +0530 message: BUG#13555854: CHECK AND REPAIR TABLE SHOULD BE MORE ROBUST [1] ISSUE: Incorrect key file. Key file is corrupted, Reading incorrect key information (keyseg) from index file. Key definition in .MYI and .FRM file differs. Starting pointer to read the keyseg information is changed to a value greater than the pack_reclength. Memcpy tries to read keyseg information from unallocated memory which causes the crash. SOLUTION: One more check added to compare the the key definition in .MYI and .FRM file. If the definition differ, server produces an error. ------------------------------------------------------------ revno: 3909 committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: imct-55 timestamp: Thu 2012-07-19 17:50:49 +0200 message: Fix -Werror build breakage ------------------------------------------------------------ revno: 3908 [merge] committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: imct-55 timestamp: Thu 2012-07-19 15:58:07 +0200 message: null upmerge ------------------------------------------------------------ revno: 2661.810.50 committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: imct-51 timestamp: Thu 2012-07-19 15:55:41 +0200 message: Reverting broken configure/make stuff ------------------------------------------------------------ revno: 3907 committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: imct-55 timestamp: Thu 2012-07-19 13:37:38 +0200 message: Fix cmake file broken by merge from 5.1 ------------------------------------------------------------ revno: 3906 [merge] committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: imct-55 timestamp: Thu 2012-07-19 13:01:33 +0200 message: upmerge 14035452 5.1 -> 5.5 ------------------------------------------------------------ revno: 2661.810.49 committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: imct-51 timestamp: Thu 2012-07-19 12:57:36 +0200 message: Bug #14035452 - MODULARIZE MYSQL_CLIENT_TEST Added new minimal client using same framework Added internal test using it Small changes to top level make/configure/cmake to have it built ------------------------------------------------------------ revno: 3905 [merge] committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.5-13955256 timestamp: Thu 2012-07-19 14:14:03 +0530 message: Bug #12615411 - server side help doesn't work as first statement Merged from mysql-5.1 to mysql-5.5 ------------------------------------------------------------ revno: 2661.810.48 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: mysql-5.1-13955256 timestamp: Thu 2012-07-19 13:52:34 +0530 message: Bug #12615411 - server side help doesn't work as first statement Problem description: Giving "help 'contents'" in the mysql client as a first statement gives error Analysis: In com_server_help() function the "server_cmd" variable was initialised with buffer->ptr(). And the "server_cmd" variable is not updated since we are passing "'contents'"(with single quote) so the buffer->ptr() consists of the previous buffer values and it was sent to the mysql_real_query() hence we are getting error. Fix: We are not initialising the "server_cmd" variable and we are updating the variable with "server_cmd= cmd_buf" in any of the case i.e with single quote or without single quote for the contents. As part of error message improvement, added new error message in case of "help 'contents'". ------------------------------------------------------------ revno: 3904 [merge] committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2012-07-18 15:18:15 +0530 message: Merge from 5.1 to 5.5 ------------------------------------------------------------ revno: 2661.810.47 committer: Chaithra Gopalareddy <chaithra.gopalareddy@oracle.com> branch nick: mysql-5.1 timestamp: Wed 2012-07-18 14:36:08 +0530 message: Bug#11762052: 54599: BUG IN QUERY PLANNER ON QUERIES WITH "ORDER BY" AND "LIMIT BY" CLAUSE PROBLEM: When a 'limit' clause is specified in a query along with group by and order by, optimizer chooses wrong index there by examining more number of rows than required. However without the 'limit' clause, optimizer chooses the right index. ANALYSIS: With respect to the query specified, range optimizer chooses the first index as there is a range present ( on 'a'). Optimizer then checks for an index which would give records in sorted order for the 'group by' clause. While checking chooses the second index (on 'c,b,a') based on the 'limit' specified and the selectivity of 'quick_condition_rows' (number of rows present in the range) in 'test_if_skip_sort_order' function. But, it fails to consider that an order by clause on a different column will result in scanning the entire index and hence the estimated number of rows calculated above are wrong (which results in choosing the second index). FIX: Do not enforce the 'limit' clause in the call to 'test_if_skip_sort_order' if we are creating a temporary table. Creation of temporary table indicates that there would be more post-processing and hence will need all the rows. This fix is backported from 5.6. This problem is fixed in 5.6 as part of changes for work log #5558 ------------------------------------------------------------ revno: 3903 committer: Nuno Carvalho <nuno.carvalho@oracle.com> branch nick: mysql-5.5 timestamp: Fri 2012-07-13 10:04:59 +0100 message: BUG#14310067: RPL_CANT_READ_EVENT_INCIDENT AND RPL_BUG41902 FAIL ON 5.5 rpl_cant_read_event_incident: Slave applies updates from bug11747416_32228_binlog.000001 file which contains a CREATE TABLE t statement and an incident, when SQL thread is running slowly IO thread may reach the incident before SQL thread executes the create table statement. Execute "drop table if exists t" and also perform a RESET MASTER to clean slave binary logs. rpl_bug41902: Error "MYSQL_BIN_LOG::purge_logs was called with file ./master-bin.000001 not listed in the index." suppression is not considering windows path, there is ".\master-bin.000001". Changed suppression to: "MYSQL_BIN_LOG::purge_logs was called with file ..master-bin.000001 not listed in the index", to match ".\" and "./". ------------------------------------------------------------ revno: 3902 [merge] committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2012-07-12 16:48:21 +0530 message: Merging from mysql-5.1 to mysql-5.5. ------------------------------------------------------------ revno: 2661.810.46 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.1 timestamp: Thu 2012-07-12 16:42:07 +0530 message: Bug #11765218 58157: INNODB LOCKS AN UNMATCHED ROW EVEN THOUGH USING RBR AND RC Description: When scanning and locking rows with < or <=, InnoDB locks the next row even though row based binary logging and read committed is used. Solution: In the handler, when the row is identified to fall outside of the range (as specified in the query predicates), then request the storage engine to unlock the row (if possible). This is done in handler::read_range_first() and handler::read_range_next(). ------------------------------------------------------------ revno: 3901 author: hery.ramilison@oracle.com committer: Hery Ramilison <hery.ramilison@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2012-07-11 18:51:07 +0200 message: Raise version number after cloning 5.5.27 ------------------------------------------------------------ revno: 3900 [merge] tags: mysql-5.5.27, clone-5.5.27-build committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2012-07-11 15:34:38 +0200 message: Empty version change upmerge ------------------------------------------------------------ revno: 2661.810.45 author: bjorn.munch@oracle.com committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: mysql-5.1 timestamp: Wed 2012-07-11 15:18:34 +0200 message: Raise version number after cloning 5.1.65 |