|
------------------------------------------------------------
revno: 5732 committer: Anirudh Mangipudi <anirudh.mangipudi@oracle.com> branch nick: mysql-5.6.16-release timestamp: Thu 2014-01-09 20:13:58 +0530 message: Bug#18047812: RESULT FILE MISMATCH DUE TO COPYRIGHT YEAR IN OUTPUT Problem: Copyright mismatch is causing test failure. Solution: Replacing the present year (2014) as the copyright year. ------------------------------------------------------------ revno: 5731 committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com> branch nick: mysql-5.6.16-release timestamp: Thu 2014-01-09 13:40:11 +0100 message: Updated release version ------------------------------------------------------------ revno: 5730 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.6.16-release timestamp: Wed 2014-01-08 14:55:14 +0100 message: Bug#18046811 COMPILATION ERRORS WHILE BUILDING MYSQL-5.6.16 ON SOLARIS 10 Include my_config.h before any system headers, to avoid Warning (Anachronism): Attempt to redefine _FILE_OFFSET_BITS without using #undef. Include <stdio.h> before <vector> to avoid "/usr/include/floatingpoint.h", line 164: Error: FILE is not defined." "/usr/include/stdio.h", line 82: Error: Multiple declaration for std::FILE." (this must be a bug in the solaris header files) ------------------------------------------------------------ revno: 5729 committer: Murthy Narkedimilli <murthy.narkedimilli@oracle.com> branch nick: mysql-5.6.16-release timestamp: Wed 2014-01-08 11:16:17 +0100 message: Correcting the version, and updating the current copyright year which reflects in the MySQL welcome message. ------------------------------------------------------------ revno: 5728 committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com> branch nick: mysql-5.6.16-release timestamp: Tue 2014-01-07 19:09:54 +0100 message: Fix for fedora and rpm uln package build ------------------------------------------------------------ revno: 5727 [merge] committer: Vishal Chaudhary <vishal.chaudhary@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2014-01-06 12:04:40 +0100 message: Empty version change upmerge ------------------------------------------------------------ revno: 2875.437.321 author: laasya.moduludu@oracle.com committer: Laasya Moduludu <laasya.moduludu@oracle.com> branch nick: mysql-5.5 timestamp: Mon 2014-01-06 11:43:05 +0100 message: Raise version number after cloning 5.5.36 ------------------------------------------------------------ revno: 5726 author: vishal.chaudhary@oracle.com committer: Vishal Chaudhary <vishal.chaudhary@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2014-01-06 11:43:05 +0100 message: Raise version number after cloning 5.6.16 ------------------------------------------------------------ revno: 5725 tags: clone-5.6.16-build committer: Jimmy Yang <jimmy.yang@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2014-01-06 16:24:28 +0800 message: Fix #Bug 17800829 - MEMCACHED.MEMC247_CACHE_POLICY CRASHES IN PB2 WITH ASSERTION `IT->SLABS_CLSID rb://3890 approved by Sunny Bains ------------------------------------------------------------ revno: 5724 [merge] committer: Murthy Narkedimilli <murthy.narkedimilli@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2014-01-06 11:33:08 +0530 message: Update/added copyright headers ------------------------------------------------------------ revno: 2875.437.320 tags: clone-5.5.36-build committer: Murthy Narkedimilli <murthy.narkedimilli@oracle.com> branch nick: mysql-5.5 timestamp: Mon 2014-01-06 10:52:35 +0530 message: Updated/added copyright headers ------------------------------------------------------------ revno: 5723 committer: Murthy Narkedimilli <murthy.narkedimilli@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2014-01-06 10:53:19 +0530 message: Updated/added copyright headers ------------------------------------------------------------ revno: 5722 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: 5.6 timestamp: Fri 2014-01-03 15:38:15 +0530 message: Bug #17209750 OLD FILES NOT BEING REMOVED FROM PERFORMANCE_SCHEMA.FILE_INSTANCES The test case is having issues(basically some timining issues). Need to refactor the test case. Hence removed for time being. ------------------------------------------------------------ revno: 5721 committer: Sujatha Sivakumar <sujatha.sivakumar@oracle.com> branch nick: Bug17842137_mysql-5.6 timestamp: Thu 2014-01-02 11:01:12 +0530 message: Bug#17842137:ASSERT IN ROW BASED REPLICATION WHEN TRANSACTION CACHE SIZE IS EXACTLY 32768 Problem: ======== When the binlog's IO_CACHE grows up to exact 32768 bytes it causes binlog events to get corrupt, if this transaction precedes with a transaction whose IO_CACHE size is >32768. Analysis: ======== On the master during the execution of a transaction all the events that are related to that transaction will be written to the IO_CACHE. The size of the IO_CACHE is 32768. The transaction whose events can fit within the IO_CACHE are never flushed to disk. During flush operation they do nothing but simply set the cache->read_end and end_of_file to current size. At the time of writing to the binlog the cache is read back and if CRC is enabled checksum is calculated if not then the content is written to binlog file. If the transaction size exceeds 32768 then it will be written to a temporary file and the cache is reinited so that remaining events can be written to cache. During writing to binary log file this temp file is read back. In the bug scenario the transaction size grows exactly to 32768, and during flush operation it expects current size of cache to be < 32768. Which is incorrect ideally it should have been <= 32768. As the size is still equal to IO_CACHE size. Because of the incorrect check cache is marked for flush but the writing function "my_b_write" doesn't flush the buffer to disk as it expects cache size to be > 32768 and the cache is reinited without writing to temp file. When the cache is read back it finds the buffer to be empty and tries to fill it from temp file which wrong. Hence the buffer is filled with some other transaction related data causing corruption. Fix: === During flush the check for size has been changed from "<" to "<=". ------------------------------------------------------------ revno: 5720 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-31 12:29:00 +0900 message: Follow up for Bug#16249481 fix. If flush_rbt is active (in recovery phase), buf_page_t::space and buf_page_t::offset cannot be invalidated until the bpage is removed from flush_list. * revno: 5677 * committer: Sunny Bains <Sunny.Bains@Oracle.Com> * branch nick: 5.6 * timestamp: Tue 2013-12-10 14:30:34 +0530 * message: * Bug#16249481 - INNODB DOES NOT SCALE WELL ON 12 CORE SYSTEM FOR SPECIFIC ALL IN MEMORY SELECT * * Add a new build option: INNODB_PAGE_ATOMIC_REF_COUNT, default is ON. * * If this option is enabled then use atomic reference counting to track * block use. If it is off then use the old way. * * Approved by Yasufumi Kinoshita rb#3958. ------------------------------------------------------------ revno: 5719 committer: Ashish Agarwal<ashish.y.agarwal@oracle.com> branch nick: bug_17065383 timestamp: Mon 2013-12-30 13:40:45 +0530 message: Bug#17065383: PASSWORD VALIDATE PLUGIN STORES HASH OF LOWERCASE PASSWORD BY MISTAKE PROBLEM: Dictionary check was done on the original password string (converting it to lowercase), which leads to storing a wrong password hash for the user. SOLUTION: A copy of the string is created and all the string comparisons is done on it. ------------------------------------------------------------ revno: 5718 [merge] committer: Arun Kuruvila <arun.kuruvila@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2013-12-30 12:00:48 +0530 message: Merging from mysql-5.5 to mysql-trunk. ------------------------------------------------------------ revno: 2875.437.319 committer: Arun Kuruvila <arun.kuruvila@oracle.com> branch nick: mysql-5.5 timestamp: Mon 2013-12-30 11:39:55 +0530 message: Bug #16324629 : SERVER CRASHES ON UPDATE/JOIN FEDERATED + LOCAL TABLE WHEN ONLY 1 LOCAL ROW Description: When updating a federated table with UPDATE... JOIN, the server consistently crashes with Signal 11 when only 1 row exists in the local table involved in the join and that 1 row can be joined with a row in the federated table. Analysis: Interaction between the federated engine and the optimizer results in the crash. In our scenario, ie, local table having only one row, the program is following a different path because the table is treated as a constant table by the join optimizer. So in this scenario "index_read()" is happening in the prepare phase, since optimizer plan is different for constant table joins. In this case, "index_read_idx_map()" (inside handler.cc) is calling "index_read()" and inside "index_read()", matching rows are fetched and "stored_result" gets populated by calling "store_result()". And just after "index_read()", "index_end()" function is called. And in the "index_end()", its freeing the "stored_result" by calling "free_result()". So when it reaches the execution phase, in "position()" function, we are getting assertion at "DBUG_ASSERT(stored_result);". In all other scenarios (ie, table with more than 1 row), optimizer plan is different and "index_read()" is happening in the execution phase. Fix: So my fix is to have a separate ha_federated member function for "index_read_idx_map()" which will handle federated engine separately. So that position() will be called before index_end() call in constant table scenario. ------------------------------------------------------------ revno: 5717 [merge] committer: Aditya A <aditya.a@oracle.com> branch nick: mysql-5.6 timestamp: Sun 2013-12-29 17:10:21 +0530 message: Bug#12762390 SHOW INNODB STATUS REPORTS NON-FK ERRORS IN THE FK SECTION [Merge from 5.5] ------------------------------------------------------------ revno: 2875.437.318 committer: Aditya A <aditya.a@oracle.com> branch nick: mysql-5.5 timestamp: Sun 2013-12-29 16:55:24 +0530 message: Bug#12762390 SHOW INNODB STATUS REPORTS NON-FK ERRORS IN THE FK SECTION ANALYSIS -------- Any error during the renaming of the table was incorrectly logged in the dict_foreign_err_file and it showed up in foreign key section when we give the query "show engine innodb status". FIX --- Prevent renaming error from being logged in dict_foreign_err_file section. [Aprooved by marko #rb 2501 ] ------------------------------------------------------------ revno: 5716 committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com> branch nick: mysql_5_6 timestamp: Sat 2013-12-28 22:08:40 +0530 message: Bug#17862905: MYSQLDUMP CREATES USELESS METADATA LOCKS Problem Description: -------------------- While taking the backup using tool "mysqldump" with option "--single-transaction", MDL lock is acquired on each table dumped. But these locks are not released until the backup operation is completed. Any concurrent DDL operation on those tables will be blocked until backup operation is completed. Moreover such blocked DDL operations will also block other concurrent DML operations (Since DDL has priority over DML) creating pile-up. Note that officially mysqldump --single-transaction is documented as not working/not supported in presence of concurrent DDL statements. But it might work for some people in some scenarios and before 5.5, due to absence of MDL, combination of "mysqldump --single-transaction" and concurrent DDL didn't create pile-up of DML statements. Analysis: -------------------- "mysqldump" start transaction with consistent snapshot and sets isolation level to "repeatable read" when it is used with option "--single-transaction". Data of all the tables is dumped using SELECT statement as part of this transaction. MDL lock SR is taken on all these tables and held till the transaction is committed or rolled back. Any other incompatible MDL lock request on these tables will wait until timeout or "mysqldump" operation is completed. As result concurrent DDL operations on the tables which were dumped will be blocked till the end of dump or timeout. Note that once table is dumped it won't be used again by "mysqldump". This fact and the fact that "mysqldump --single-transactions" produces backup with validity point at the start of transaction (and also retrieves binlog position for backup at the start of transaction) means that "mysqldump --single-transaction" can release MDL on tables which it has already dumped without introducing more problems with consistency. Fix: -------------------- To make "mysqldump --single-transaction" to release locks once dumping of the table is done, modified mysqldump client code to dump table data after setting a savepoint. Once dumping of table data is over, added code to rollback to the savepoint set. Rolling back to savepoint will release MDL lock acquired for the table. But as of now, on rollback to savepoint, MDL locks are not released if binlog is on. This logic is added to avoid dropping of tables before rollback to savepoint event is written to binlog. But when binlog handlerton can clear cache and can safely rollback to savepoint without writing an event for rollback to savepoint then also we are not releasing the MDL locks. This is fixed by introducing a new handlerton function call savepoint_rollback_can_release_mdl. We call this function to check with each storage engine participating in transaction whether it is safe to release MDL after rollback to savepoint. Metadata locks are released only if all the storage engines agreed that it is a safe thing to do. 1) For InnoDB storage engine this handlerton function can allow release of MDL locks if transaction has not acquired any InnoDB locks. 2) For Binlog this handlerton function can allow release of MDL locks if rollback to savepoint will completely remove any traces of transaction from cache. 3) Absence of this method for any storage engine means it is not safe to release MDL locks. Note that this patch doesn't make "mysqldump --single-transaction" safe in general case in presence of concurrent DDL. Nor makes it officially supported in this case. It just allows to avoid problem with unnecessary concurrent DDL blocking and associated DML query pile-up in some specific cases when it might work. ------------------------------------------------------------ revno: 5715 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: 5.6 timestamp: Fri 2013-12-27 14:11:20 +0530 message: Bug #17209750 OLD FILES NOT BEING REMOVED FROM PERFORMANCE_SCHEMA.FILE_INSTANCES Description: "When a file is deleted from the disk, it is also removed from the file_instances table." This is not true on either 5.5.23 or 5.6.11. When there are three relay log files on disk, but the file_instances table lists more number of relay logs. Even this case is happening for master bin and slave bin logs. Analysis: When we are deleting the slave-relay-bin/master-bin/slave-bin log files we were using the my_delete() function which is not P_S instrumented function. Hence, the files are not removed from the file_instances table. Fix: As part of the fix we replaced my_delete() function with P_S instrumented mysql_file_delete() function. ------------------------------------------------------------ revno: 5714 committer: Shaohua Wang <shaohua.wang@oracle.com> branch nick: mysql-5.6-bugfix1 timestamp: Thu 2013-12-26 17:47:04 +0800 message: BUG#17978763 - SEGV IN FTSPARSE() BOOLEAN MODE QUERY AGAINST '\"\"@117' We check whether node is null in fts_ast_term_set_distance, and do nothing if the node is null. rb://4230 approved by Jimmy.Yang ------------------------------------------------------------ revno: 5713 [merge] committer: Satya Bodapati <satya.bodapati@oracle.com> branch nick: mysql-5.6 timestamp: Thu 2013-12-26 14:39:11 +0530 message: Merge testcase for BUG#16752251 from mysql-5.5 to mysql-5.6 ------------------------------------------------------------ revno: 2875.437.317 committer: Satya Bodapati <satya.bodapati@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2013-12-26 14:33:52 +0530 message: BUG#16752251 - INNODB DOESN'T REDO-LOG INSERT BUFFER MERGE OPERATION IF IT IS DONE IN-PLACE Add testcase as innodb-change-buffer-recovery.test ------------------------------------------------------------ revno: 5712 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-24 10:59:45 +0530 message: Fixing a pb2 issue. This test case times out under valgrind. Not running it under valgrind until further notice. ------------------------------------------------------------ revno: 5711 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2013-12-23 12:11:26 +0530 message: Bug #17991524 THE DEBUG SYNC POINT IB_CORRUPT_PAGE0 IS NOT WORKING AS EXPECTED Problem: The debug point ib_corrupt_page0 is not working reliably. This is because of the background i/o threads. If the page 0 of a tablespace is flushed by a user session (the SET command for variable innodb_buf_flush_list_now), then the debug point ib_corrupt_page0 will be enabled and will work as expected. But if the page 0 of the tablespace is flushed by a background i/o thread, then ib_corrupt_page0 will not work as expected. Solution: Removing the ib_corrupt_page0 debug point and re-writing the test case using some other means. rb#4216 approved by Jimmy. ------------------------------------------------------------ revno: 5710 committer: Aditya A <aditya.a@oracle.com> branch nick: mysql-5.6 timestamp: Sun 2013-12-22 22:07:51 +0530 message: Bug#17287443 ERROR(1030): GOT ERROR -1 FROM STORAGE ENGINE Post push test failure fix in test script. ------------------------------------------------------------ revno: 5709 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.6 timestamp: Fri 2013-12-20 19:14:13 +0530 message: Fixing a pb2 issue. The combination gcov + embedded + crash test does not work. ------------------------------------------------------------ revno: 5708 committer: Neeraj Bisht <neeraj.x.bisht@oracle.com> branch nick: 5.6 timestamp: Fri 2013-12-20 15:15:00 +0530 message: Bug#16539903 - SERVER CRASHES IN IN HA_MYISAM::FT_INIT_EXT WITH A FROM SUBQUERY Problem:- Full-text search combined with derived tables causes a segment fault. Analysis:- In query like EXPLAIN SELECT MATCH(ft) AGAINST( "test" IN BOOLEAN MODE) FROM ( SELECT ft FROM t1 ) AS t; We are creating a temporary table for the subquery result table. But after wl-5274(where we are postponed materialization), we will create tmp table, but skip instantiation of temporary table. When we have full-text function in our main select query, we are going to call Item_func_match::init_search() for all the full-text item. There we are going to take care about condition like --> match ... against (null) and we are going to call handler::ft_init_ext(), which is used to Initialize full-text index scan(which need table to be initialized). but as we havnt initialized the table. This cause a segmentation fault. Solution:- When we have derived tables, instead of intializing full-text function at optimization, we will initiate it at the time of execution . ------------------------------------------------------------ revno: 5707 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.6 timestamp: Fri 2013-12-20 12:05:46 +0530 message: BUG 17335427 - INNODB CAN NOT USE THE DOUBLEWRITE BUFFER PROPERLY Problem: Fixing a memory issue in my original fix. This was identified from PB2 failures. If the page is uncompressed, then its size must be equal to UNIV_PAGE_SIZE. The buf_page_is_corrupted() assumes the size of the uncompressed pages as equal to UNIV_PAGE_SIZE. Solution: Call buf_page_is_corrupted() for uncompressed pages only if page size is equal to UNIV_PAGE_SIZE. approved by Yasufumi over IM. ------------------------------------------------------------ revno: 5706 committer: Aditya A <aditya.a@oracle.com> branch nick: mysql-5.6 timestamp: Fri 2013-12-20 11:22:30 +0530 message: Bug#17287443 ERROR(1030): GOT ERROR -1 FROM STORAGE ENGINE PROBLEM ------- When we try to do DML operations in innodb force recovery mode.we get a cryptic error message. ERROR(1030): GOT ERROR -1 FROM STORAGE ENGINE FIX --- Introduced a new error ER_INNODB_FORCE_RECOVERY which will print proper error message. [Approved by Kevin and Krunal #rb4095 and rb#4137] ------------------------------------------------------------ revno: 5705 [merge] committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: 5.6 timestamp: Thu 2013-12-19 16:29:20 +0530 message: Bug #17780290 PUBLISH THE GIS TEST FOR BUG#16451878 Merging from 5.5 to 5.6 ------------------------------------------------------------ revno: 2875.437.316 committer: Venkata Sidagam <venkata.sidagam@oracle.com> branch nick: 5.5 timestamp: Thu 2013-12-19 16:08:38 +0530 message: Bug #17780290 PUBLISH THE GIS TEST FOR BUG#16451878 Adding the test cases for the BUG#16451878. ------------------------------------------------------------ revno: 5704 committer: Aditya A <aditya.a@oracle.com> branch nick: mysql-5.6 timestamp: Thu 2013-12-19 16:06:45 +0530 message: Bug#17448389 SYS_DATAFILES TABLE IS NOT UPDATED AFTER RECOVERY FOR TABLES WITH .ISL PATH PROBLEM ------- If user changes updates the path of .ibd files in *.isl files and does a crash recovery then tables are loaded from the updated path,but SYS_DATAFILES are not updated. Now if the user stops and restarts the server in normal mode ,it will detect that the there are two different copies of data directory (one in isl file and one in SYS_DATAFILES table) and both are valid ( we have not deleted the ibd file from the original path) and refuse to load the table and ask user to resolve the conflict. FIX --- Update the SYS_DATFILES to reflect the updated path after crash recovery. [Aprroved by Kevin rb#4177] ------------------------------------------------------------ revno: 5703 committer: Annamalai Gurusami <annamalai.gurusami@oracle.com> branch nick: mysql-5.6 timestamp: Thu 2013-12-19 13:20:50 +0530 message: Bug #17335427 INNODB CAN NOT USE THE DOUBLEWRITE BUFFER PROPERLY Problem: If the first page (page 0) of the single table tablespace is corrupted in the data file then our recovery doesn't progress even if there is a clean copy of the same available in the double write buffer. Analysis: During recovery, our first step is to process the double write buffer. We look at the pages in the double write buffer and determine its (space_id, page_no) details. Each of the page in the double write buffer corresponds to a page in the .ibd data file. Using the space_id information we need to map the page in the double write buffer to the corresponding ibd file. This is done by reading the space_id information from the first page of the single table tablespace. If the first page of the single table tablespace is corrupted, then we are unable to determine the data file to which a particular page in the double write buffer belongs to. So we need to explore and see if we can determine the space_id in other means. Solution: Assume a particular page size. Read N number of pages from the ibd file. Ignore the corrupted pages and determine the (space_id, page_size and zip_size) information. Repeat this for all supported page sizes. Using this approach determine the correct (space_id, page_size and zip_size) of the ibd file. rb#4025 approved by Yasufumi. ------------------------------------------------------------ revno: 5702 committer: Thirunarayanan B<thirunarayanan.balathandayuth@oracle.com> branch nick: r-5.6 timestamp: Thu 2013-12-19 11:44:13 +0530 message: Bug #16868967 MYSQL USES SIGNIFICANTLY MORE MEMORY FOR ALTER TABLE THAN EXPECTED Problem: During online alter table, an online log buffer would be created for index that is being rebuilt or created. This online log contains two buffers - head and tail. Alter table takes lot of memory than expected even there is no concurrent write for index. But Both head and tail buffer will be useful when there is a concurrent write on the index. If there are many partitions involved, it is unlikely that all the partitions would be modified concurrently. Solution: Allocate the tail buffer only when first DML statement happens on the index. Allocate the head buffer only in apply phase and freed at the end of the apply phase. Approved by Marko rb#3850 ------------------------------------------------------------ revno: 5701 committer: horst.hunger@oracle.com branch nick: mysql-5.6 timestamp: Wed 2013-12-18 15:39:57 +0100 message: Request by development to run memcached in 5.6 ------------------------------------------------------------ revno: 5700 [merge] committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: main-56 timestamp: Wed 2013-12-18 14:03:30 +0100 message: Followup fix for Bug 17827378 MTR DOES NOT REPORT IF A TEST FAILS TO DROP CREATED EVENTS: - Check for triggers should exclude mtr's own - Move the code to before checksum table as it might affects result of some autdit_log tests - Remove duplicated show status like 'slave_open_temp_tables'; ------------------------------------------------------------ revno: 2875.437.315 committer: Bjorn Munch <bjorn.munch@oracle.com> branch nick: main-55 timestamp: Wed 2013-12-18 14:01:15 +0100 message: Followup fix for Bug 17827378 MTR DOES NOT REPORT IF A TEST FAILS TO DROP CREATED EVENTS: - Check for triggers should exclude mtr's own - Move the code to before checksum table as it might affect result of some autdit_log tests (does in 5.6) - Replace SHOW STATUS LIKE 'slave_open_temp_tables' to be like in 5.6 ------------------------------------------------------------ revno: 5699 [merge] committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.6-merge timestamp: Wed 2013-12-18 11:17:16 +0100 message: merge 5.5 => 5.6 ------------------------------------------------------------ revno: 2875.437.314 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.5 timestamp: Wed 2013-12-18 11:08:21 +0100 message: MTR's internal check of the test case 'main.events_trans' failed. fix: DROP EVENT e1; ------------------------------------------------------------ revno: 2875.437.313 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.5 timestamp: Wed 2013-12-18 11:05:18 +0100 message: Bug#16316074 RFE: MAKE TMPDIR A BUILD-TIME CONFIGURABLE OPTION Bug#68338 RFE: make tmpdir a build-time configurable option Background: Some distributions use tmpfs for mounting /tmp by default, which has some advantages, but brings also new issues. Fedora started using tmpfs on /tmp in version 18 for example. If not configured otherwise in my.cnf, MySQL uses system's constant P_tmpdir expanded to /tmp on Linux. This can introduce some problems with limited space in /tmp and also some data loss in case of replication slave [1]. In case distributions would like to use /var/tmp, which should be better for MySQL purposes, then we have to patch the source or change tmpdir option in my.cnf, which is however not updated in case it has already existed. Thus, it would be useful to be able to specify default tmpdir path using a configure option, while using P_tmpdir in case it is not defined explicitly. Based on a contribution from Honza Horak ------------------------------------------------------------ revno: 5698 [merge] committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com> branch nick: mysql-5.6 timestamp: Wed 2013-12-18 13:55:27 +0530 message: Bug17632978 SLAVE CRASHES IF ROW EVENT IS CORRUPTED (MYSQLBINLOG -V CRASHES WITH THAT BINLOG) Merging fix from mysql-5.5 Post-Push: Fix Werror-build problem ------------------------------------------------------------ revno: 2875.437.312 committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2013-12-18 13:52:49 +0530 message: Bug17632978 SLAVE CRASHES IF ROW EVENT IS CORRUPTED (MYSQLBINLOG -V CRASHES WITH THAT BINLOG) Post Push: Fixing Werror compiler issue ------------------------------------------------------------ revno: 5697 [merge] committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-17 22:26:45 +0530 message: Bug17632978 SLAVE CRASHES IF ROW EVENT IS CORRUPTED (MYSQLBINLOG -V CRASHES WITH THAT BINLOG) Merging fix from mysql-5.5 ------------------------------------------------------------ revno: 2875.437.311 committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com> branch nick: mysql-5.5 timestamp: Tue 2013-12-17 22:11:22 +0530 message: Bug#17632978 SLAVE CRASHES IF ROW EVENT IS CORRUPTED (MYSQLBINLOG -V CRASHES WITH THAT BINLOG) Problem: If slave receives a corrupted row event, slave server is crashing. Analysis: When slave is unpacking the row event, it is not validating the data before applying the event. If the data is corrupted for eg: the length of a field is wrong, it could end up reading wrong data leading to a crash. A similar problem happens when mysqlbinlog tool is used against a corrupted binlog using '-v' option. Due to -v option, the tool tries to print the values of all the fields. Corrupted field length could lead to a crash. Fix: Before unpacking the field, a verification will be made on the length. If it falls into the event range, only then it will be unpacked. Otherwise, "ER_SLAVE_CORRUPT_EVENT" error will be thrown. Incase mysqlbinlog -v case, the field value will not be printed and the processing of the file will be stopped. ------------------------------------------------------------ revno: 5696 committer: Venkatesh Duggirala<venkatesh.duggirala@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-17 17:13:02 +0530 message: BUG#17544169 MYSQLBINLOG -V DOES NOT PROPERLY DECODE DECIMAL VALUES IN AN RBR LOG Analysis: If verbose (-v) option is used in mysqlbinlog tool it decodes a RBR event into the query (the same query which was used at source to generate) and displays immediately after displaying the row event in the output. The algorithm used to display the decimal was wrongly written which were causing problems similar to the ones mentioned below. Eg: -0.938582 is decoded as: -938582000.000000000 4294967296.001 as: 000000004.294967296.001000000.000000000 Fix: 'decimal2string' is an existing function which converts a decimal value into a string format. Hence the algorithm used was replaced with this existing 'decimal2string' function to avoid problems mentioned above. After this fix, decimal will be printed exactly the same way how they get printed in 'select' command output. Eg: -0.938582 for decimal(10,10) will be displayed as -0.938582000. 4294967296.001 for decimal(20,10) will be displayed as 4294967296.0010000000 ------------------------------------------------------------ revno: 5695 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-17 20:30:16 +0900 message: Follow up for Bug#16249481 fix. backport from mysql-trunk revno: 7152 committer: Vasil Dimov <vasil.dimov@oracle.com> branch nick: mysql-trunk timestamp: Tue 2013-12-17 11:29:47 +0200 message: Followup to sunny.bains@oracle.com-20131210092144-0xfzdmj5vgqlqpq2 Fix a compilation failure on Win32: buf0buf.ic(1016): error C2664: '_InterlockedExchangeAdd' : cannot convert parameter 1 from 'ib_uint32_t *' to 'volatile long *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast ------------------------------------------------------------ revno: 5694 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-17 20:03:26 +0900 message: Follow up for Bug#16249481 fix. Atomic operation macro for Soralis and Windows added by Bug#16249481 fix were wrong. Aligned same for mysql-trunk. * revno: 5677 * committer: Sunny Bains <Sunny.Bains@Oracle.Com> * branch nick: 5.6 * timestamp: Tue 2013-12-10 14:30:34 +0530 * message: * Bug#16249481 - INNODB DOES NOT SCALE WELL ON 12 CORE SYSTEM FOR SPECIFIC ALL IN MEMORY SELECT * * Add a new build option: INNODB_PAGE_ATOMIC_REF_COUNT, default is ON. * * If this option is enabled then use atomic reference counting to track * block use. If it is off then use the old way. * * Approved by Yasufumi Kinoshita rb#3958. ------------------------------------------------------------ revno: 5693 committer: Jorgen Loland <jorgen.loland@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-17 10:45:12 +0100 message: BUG#17889511 fix test errors ------------------------------------------------------------ revno: 5692 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2013-12-16 21:03:59 +0900 message: The fix for Bug#16249481 was not enabled for builds. "#cmakedefine INNODB_PAGE_ATOMIC_REF_COUNT" is added to config.h.cmake Patch made by Sunny Bains (by mail) Approved by Yasufumi Kinoshita * revno: 5677 * committer: Sunny Bains <Sunny.Bains@Oracle.Com> * branch nick: 5.6 * timestamp: Tue 2013-12-10 14:30:34 +0530 * message: * Bug#16249481 - INNODB DOES NOT SCALE WELL ON 12 CORE SYSTEM FOR SPECIFIC ALL IN MEMORY SELECT * * Add a new build option: INNODB_PAGE_ATOMIC_REF_COUNT, default is ON. * * If this option is enabled then use atomic reference counting to track * block use. If it is off then use the old way. * * Approved by Yasufumi Kinoshita rb#3958. ------------------------------------------------------------ revno: 5691 committer: Jorgen Loland <jorgen.loland@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2013-12-16 08:40:11 +0100 message: Bug#17889511: FORCE INDEX UNABLE TO FORCE AN ORDER BY WITH JOIN "FORCE INDEX [FOR ORDER BY] (indexName)" did not work for joins because test_if_skip_sort_order() contains a heuristic that table scan + join cache tends to be cheaper than an index scan. While the heuristic may be correct, it should not override the users explicit request to use the index. This patch also changes the warning created for EXPLAIN. Instead of printing only "IGNORE/USE/FORCE INDEX" it now also prints "FOR [GROUP BY|ORDER BY|JOIN]" if this was specified in the query. ------------------------------------------------------------ revno: 5690 committer: Thirunarayanan B<thirunarayanan.balathandayuth@oracle.com> branch nick: r-5.6 timestamp: Mon 2013-12-16 12:29:20 +0530 message: Bug #16924719 SMALL PERFORMANCE IMPACT WITH HEAP BLOCK DEBUGGING INFO IN RELEASE BUILDS Problem: Memory block debugging details (file_name, lineno) is present on release builds.It impacts by a tiny amount on every heap creation. Solution: Removed the file_name, line no parameters from mem_heap_create_func() and mem_alloc_func() in release builds. [Approved by Marko #rb 4022] ------------------------------------------------------------ revno: 5689 [merge] committer: Kent Boortz <kent.boortz@oracle.com> branch nick: mysql-5.6 timestamp: Sat 2013-12-14 13:11:48 +0100 message: Merge mysql-5.5 --> mysql-5.6 ------------------------------------------------------------ revno: 2875.437.310 committer: Kent Boortz <kent.boortz@oracle.com> branch nick: mysql-5.5 timestamp: Sat 2013-12-14 13:05:36 +0100 message: Bug#29716 : Bug#11746921 : MYSQL_INSTALL_DB REFERS TO THE (OBSOLETE) MYSQLBUG SCRIPT DURING INSTALLATION Bug#68742 : Bug#16530527 : OBSOLETE BUGREPORT ADDRESSES ------------------------------------------------------------ revno: 5688 committer: Shaohua Wang <shaohua.wang@oracle.com> branch nick: mysql-5.6-bugfix1 timestamp: Fri 2013-12-13 17:56:54 +0800 message: Bug#17033591 5.6.12 REMOVED UNIV_SYNC_DEBUG FROM UNIV_DEBUG Enable UNIV_SYNC_DEBUG and fix fts test failures. rb://4139 approved by Marko and Jimmy. ------------------------------------------------------------ revno: 5687 [merge] committer: Marc Alff <marc.alff@oracle.com> branch nick: mysql-5.6-push timestamp: Fri 2013-12-13 10:42:34 +0100 message: Merge mysql-5.5 --> mysql-5.6 ------------------------------------------------------------ revno: 2875.437.309 [merge] committer: Marc Alff <marc.alff@oracle.com> branch nick: mysql-5.5-push timestamp: Fri 2013-12-13 10:26:05 +0100 message: Push to mysql-5.5 ------------------------------------------------------------ revno: 2875.465.1 committer: Marc Alff <marc.alff@oracle.com> branch nick: mysql-5.5-bug17928281 timestamp: Wed 2013-12-11 11:15:23 +0100 message: Bug#17928281 'CHECK_PERFORMANCE_SCHEMA()' LEAVES 'CURRENT_THD' REFERRING DESTRUCTED THD OBJ Prior to fix, function check_performance_schema() could leave behind stale pointers in thread local storage, for the following keys: - THR_THD (used by _current_thd) - THR_MALLOC (used for memory allocation) This is an unsafe practice, which can potentially cause crashes, and that can cause other bugs when code is modified during maintenance. With this fix, thread local storage keys used temporarily within function check_performance_schema() are cleaned up after use. ------------------------------------------------------------ revno: 5686 committer: mithun <mithun.c.y@oracle.com> branch nick: mysql-5.6 timestamp: Fri 2013-12-13 11:09:40 +0530 message: Bug #17513341 : >=4G JOIN_BUFFER_SIZE CRASH WHEN JOINING TABLES, VIEWS ISSUE : 1. Offset address from a join buffer of size >=4gb can be >4 bytes long. But we have only considered offsets upto 4bytes long. This will lead to invalid buffer read and memory corruption henceforth. 2. If we fail to allocate join buffer then we are not freeing the JOIN_CACHE_X instance. Now next join buffer will wrongly take this unfreed JOIN_CACHE_X instance as its previous cache. Hence in incremental join buffer implementation there will be a chance for unallocated memory access. Solution : 1. Now for join buffer >=4gb we have made offest address size = 8 bytes. 2. If we fail to allocate the join buffer we free the JOIN_CACHE_X instance also. ------------------------------------------------------------ revno: 5685 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> branch nick: mysql-5.6 timestamp: Fri 2013-12-13 13:23:34 +0900 message: Fix the possibile rare race condition at Bug#16249481 fix. Approved by Sunny Bains (IM) * revno: 5677 * committer: Sunny Bains <Sunny.Bains@Oracle.Com> * branch nick: 5.6 * timestamp: Tue 2013-12-10 14:30:34 +0530 * message: * Bug#16249481 - INNODB DOES NOT SCALE WELL ON 12 CORE SYSTEM FOR SPECIFIC ALL IN MEMORY SELECT * * Add a new build option: INNODB_PAGE_ATOMIC_REF_COUNT, default is ON. * * If this option is enabled then use atomic reference counting to track * block use. If it is off then use the old way. * * Approved by Yasufumi Kinoshita rb#3958. ------------------------------------------------------------ revno: 5684 committer: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> branch nick: mysql-5.6 timestamp: Fri 2013-12-13 12:52:47 +0900 message: The adjustment about UNIV_SUNC_DEBUG is needed for Bug#16249481 fix Approved by Sunny Bains (IM) * revno: 5677 * committer: Sunny Bains <Sunny.Bains@Oracle.Com> * branch nick: 5.6 * timestamp: Tue 2013-12-10 14:30:34 +0530 * message: * Bug#16249481 - INNODB DOES NOT SCALE WELL ON 12 CORE SYSTEM FOR SPECIFIC ALL IN MEMORY SELECT * * Add a new build option: INNODB_PAGE_ATOMIC_REF_COUNT, default is ON. * * If this option is enabled then use atomic reference counting to track * block use. If it is off then use the old way. * * Approved by Yasufumi Kinoshita rb#3958. ------------------------------------------------------------ revno: 5683 [merge] committer: sayantan dutta <sayantan.dutta@oracle.com> branch nick: mysql-5.6 timestamp: Thu 2013-12-12 12:23:02 +0530 message: Bug 17827378 5.5=>5.6 ------------------------------------------------------------ revno: 2875.437.308 committer: sayantan dutta <sayantan.dutta@oracle.com> branch nick: mysql-5.5 timestamp: Thu 2013-12-12 12:20:57 +0530 message: Bug #17827378 - MTR DOES NOT REPORT IF A TEST FAILS TO DROP CREATED EVENTS ------------------------------------------------------------ revno: 5682 committer: Vasil Dimov <vasil.dimov@oracle.com> branch nick: mysql-5.6 timestamp: Wed 2013-12-11 16:13:33 +0200 message: Backport from mysql-trunk to mysql-5.6: ** revision-id: vasil.dimov@oracle.com-20131203163459-tlkyqdq93jysk9z0 ** committer: Vasil Dimov <vasil.dimov@oracle.com> ** branch nick: mysql-trunk ** timestamp: Tue 2013-12-03 18:34:59 +0200 ** message: ** Fix Bug#70768 Persistent optimizer statistics often causes LOCK_open stalls ** ** Protect each table's dict_table_t::stat* members with a latch dedicated ** for this table instead of using a global pool of 64 shared latches. ** With 6 tables, the chances of at least two ending up with the same latch ** is 23.9%. With a lots of tables, there are tons of collisions. ** ** Reviewed by: Kevin (rb:3805) ------------------------------------------------------------ revno: 5681 committer: Roy Lyseng <roy.lyseng@oracle.com> branch nick: mysql-5.6 timestamp: Wed 2013-12-11 09:59:30 +0100 message: Bug#17600176: This query returns a row in 5.5 but not 5.6 or current 5.7 The problem query contains an IN subquery that is transformed to a semi-join. The subquery contains an outer join operation. When run standalone, the outer join in the subquery is preserved as an outer join and returns one row. However, when the full query is run, the outer join is converted into an inner join, and the subquery no longer returns any row. This causes the outer query to return no rows. The problem is with the IF clause in the WHERE clause of the subquery, When transforming into semi-join, we rely on Item::fix_after_pullout() to adjust used_tables and not_null_tables information within the condition objects, in order to determine e.g. the outer join to inner join transform. However, there is no specific implementation of ::fix_after_pullout() for the IF clause, so it returns generic information generated by Item_func::fix_after_pullout(). The fix is to add this function. By analysis, this appears to be a problem for BETWEEN predicates and IN predicates too. A specific implementation of :;fix_after_pullout() is added for both classes. In addition, it was detected that not_null_tables information was not updated correctly for class Item_row. However, I was not able to think out any failing test for this problem, so no test case was added. ------------------------------------------------------------ revno: 5680 committer: Thirunarayanan B<thirunarayanan.balathandayuth@oracle.com> branch nick: mysql-5.6 timestamp: Wed 2013-12-11 14:06:16 +0530 message: Bug #17848838 BACKPORT 16511145 TO 5.6 Backporting the fix of Bug #16511145 from trunk to mysql-5.6 [Approved by Kevin rb# 3983] ------------------------------------------------------------ revno: 5679 committer: Anil Toshniwal <anil.toshniwal@oracle.com> branch nick: mysql-5.6 timestamp: Wed 2013-12-11 13:35:55 +0530 message: Bug#16936961 INCORRECT TRANSACTION ACTIVE TIME FOR RECOVING TRANSACTION AFTER CRASH Problem: The start_time member of trx_t structure is uninitialized in trx_create(), that is, at the time of transaction object creation. The start_time was initialized only at the start of transaction. So after crash, start_time was taking the garbage value and while rollback is running in background for uncommited trx. Fixed: Initialized the start_time member in trx_resurrect_*(), when trx is in either ACTIVE or PREPARED STATE. Approved by Jimmy (rb#4046). ------------------------------------------------------------ revno: 5678 committer: Anil Toshniwal <anil.toshniwal@oracle.com> branch nick: mysql-5.6 timestamp: Wed 2013-12-11 12:30:53 +0530 message: Bug#17810862 INNOCHECKSUM.EXE CANNOT HANDLE >=4G FILES (AND PRINTS WRONG ERROR MESSAGE) Problem: 1) mysql-5.6 innochecksum tool don't support file larger than 2GB. 2) Wasn't used the Windows specific API, _stat64() to get file size, so was printing wrong error message. Solution: 1) Fixed innochecksum to provide utility to support large file also. 2) Use Windows Specific API, _stat64() to get file size. Approved by Kevin (rb#4012). ------------------------------------------------------------ revno: 5677 committer: Sunny Bains <Sunny.Bains@Oracle.Com> branch nick: 5.6 timestamp: Tue 2013-12-10 14:30:34 +0530 message: Bug#16249481 - INNODB DOES NOT SCALE WELL ON 12 CORE SYSTEM FOR SPECIFIC ALL IN MEMORY SELECT Add a new build option: INNODB_PAGE_ATOMIC_REF_COUNT, default is ON. If this option is enabled then use atomic reference counting to track block use. If it is off then use the old way. Approved by Yasufumi Kinoshita rb#3958. ------------------------------------------------------------ revno: 5676 committer: Roy Lyseng <roy.lyseng@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-10 09:24:24 +0100 message: Bug#71010: Bug#17876794: sql/sql_resolver.cc refers to partition engine fields An #ifdef was missed in this file. ------------------------------------------------------------ revno: 5675 committer: Tor Didriksen <tor.didriksen@oracle.com> branch nick: 5.6-merge timestamp: Mon 2013-12-09 09:27:28 +0100 message: Bug#17400967 MYSQL_CONFIG FAILS TO FILTER OUT SOME WARNING FLAG For clang and gcc we set some warning flags when compiling the server. Remove them when generating the script mysqld_config. ------------------------------------------------------------ revno: 5674 committer: Thirunarayanan B<thirunarayanan.balathandayuth@oracle.com> branch nick: r-5.6 timestamp: Mon 2013-12-09 11:56:43 +0530 message: Bug #16924719 SMALL PERFORMANCE IMPACT WITH HEAP BLOCK DEBUGGING INFO IN RELEASE BUILDS Fixed build problem in debug mode. ------------------------------------------------------------ revno: 5673 committer: Pavan Naik<pavan.naik@oracle.com> branch nick: mysql-5.6 timestamp: Mon 2013-12-09 11:45:35 +0530 message: BUG#16321920 : CREATE A SEPARATE INNODB_ZIP TEST SUITE innodb.innodb-wl5980-alter.test and innodb.innodb-wl6445-1.test were affecting innodb_zip.innodb-restart.test Added "rmdir" statement in the end of both the tests to remove the directory "$MYSQL_TMP_DIR/alt_dir". ------------------------------------------------------------ revno: 5672 committer: Thirunarayanan B<thirunarayanan.balathandayuth@oracle.com> branch nick: r-5.6 timestamp: Mon 2013-12-09 10:32:10 +0530 message: Bug #16924719 SMALL PERFORMANCE IMPACT WITH HEAP BLOCK DEBUGGING INFO IN RELEASE BUILDS Problem: Memory block debugging details (file_name, lineno) is present on release builds.It impacts by a tiny amount on every heap creation. Solution: Removed file_no, lineno of block details in release builds. [Approved by Marko #rb 4022] ------------------------------------------------------------ revno: 5671 committer: Vasil Dimov <vasil.dimov@oracle.com> branch nick: mysql-5.6 timestamp: Fri 2013-12-06 13:49:49 +0200 message: Backport from mysql-trunk to mysql-5.6: ** revision-id: vasil.dimov@oracle.com-20131203155950-qm0okr731tms81sy ** committer: Vasil Dimov <vasil.dimov@oracle.com> ** branch nick: mysql-trunk ** timestamp: Tue 2013-12-03 17:59:50 +0200 ** message: ** Fix Bug#17193801 DICT_TABLE_SCHEMA_CHECK CALLS DTYPE_SQL_NAME ** NEEDLESSLY - WASTING A LOT OF CPU ** ** Avoid the calls to dtype_sql_name() if the results are not going to ** be used (they are used only in an event of an error). ** ** Reviewed by: Kevin (rb:3625) ------------------------------------------------------------ revno: 5670 [merge] committer: Guilhem Bichot <guilhem.bichot@oracle.com> branch nick: 5.6 timestamp: Wed 2013-12-04 18:08:05 +0100 message: Merge of local 5.6 with latest changes of local 5.5 ------------------------------------------------------------ revno: 2875.437.307 committer: Guilhem Bichot <guilhem.bichot@oracle.com> branch nick: 5.5 timestamp: Wed 2013-12-04 12:32:42 +0100 message: Bug#16539979 - BASIC SELECT COUNT(DISTINCT ID) IS BROKEN Bug#17867117 - ERROR RESULT WHEN "COUNT + DISTINCT + CASE WHEN" NEED MERGE_WALK Problem: COUNT DISTINCT gives incorrect result when it uses a Unique Tree and its last inserted record has null value. Here is how COUNT DISTINCT is processed, given that this query is not using loose index scan. When a row is produced as a result of joining tables (there is only one table here), we store the SELECTed value in a Unique tree. This allows elimination of any duplicates, and thus implements DISTINCT. When we have processed all rows like this, we walk the Unique tree, counting its elements, in Aggregator_distinct::endup() (tree->walk()); for each element we call Item_sum_count::add(). Such function wants to ignore any NULL value, for that it checks item_sum -> args[0] -> null_value. It is a mistake: when walking the Unique tree, the value to be aggregated is not item_sum ->args[0] but rather table -> field[0]. Solution: instead of item_sum -> args[0] -> null_value, use arg_is_null(), which knows where to look (like in fix for bug 57932). As a consequence of this solution, we have to make arg_is_null() a little more general: 1) Because it was so far only used for AVG() (which always has a single argument), this function was looking at a single argument; now that it has to work with COUNT(DISTINCT expression1,expression2), it must look at all arguments. 2) Because we start using arg_is_null () for COUNT(DISTINCT), i.e. in Item_sum_count::add (), it implies that we are also using it for COUNT(no DISTINCT) (same add ()). For COUNT(no DISTINCT), the nullness to check is that of item_sum -> args[0]. But the null_value of such item is reliable only if val_*() has been called on it. So far arg_is_null() was always used after a call to arg_val*(), so could rely on null_value; but for COUNT, there is no call to arg_val*(), so arg_is_null() has to call is_null() instead. Testcase for 16539979 by Neeraj. Testcase for 17867117 contributed by Xiaobin Lin from Taobao. ------------------------------------------------------------ revno: 5669 committer: Krunal Bauskar krunal.bauskar@oracle.com branch nick: mysql-5.6 timestamp: Wed 2013-12-04 15:58:27 +0530 message: - bug#70867: WRONG OS ERROR NUMBER REPORTED IN ERROR LOG DURING FAILURE AT STARTUP InnoDB has handler to handle some of the common known errors. One of such error is ACCESS VIOLATION error which is detected and proper notifying error message is printed but it left unmapped to internal InnoDB error code that causes caller function to think that error is is not from know list and caller try to invoke default error handle leading to error-code and message mis-match. Fixed by ensuring that known ACCESS VIOLATION error is mapped to proper InnoDB error code. Approved by: Kevin (rb#3986) (BPS approval by Sveta) ------------------------------------------------------------ revno: 5668 [merge] committer: Hery Ramilison <hery.ramilison@oracle.com> branch nick: mysql-5.6 timestamp: Wed 2013-12-04 04:12:50 +0100 message: Upmerge of the mysql-5.1.73 build ------------------------------------------------------------ revno: 2875.437.306 [merge] committer: Hery Ramilison <hery.ramilison@oracle.com> branch nick: mysql-5.5 timestamp: Wed 2013-12-04 04:04:44 +0100 message: Upmerge of the mysql-5.1.73 build ------------------------------------------------------------ revno: 2661.885.1 author: committer: Hery Ramilison <hery.ramilison@oracle.com> branch nick: mysql-5.1 timestamp: Tue 2013-12-03 20:47:36 +0100 message: Merge from mysql-5.1.73-release ------------------------------------------------------------ revno: 5667 [merge] author: vishal.chaudhary@oracle.com committer: Vishal Chaudhary <vishal.chaudhary@oracle.com> branch nick: mysql-5.6 timestamp: Tue 2013-12-03 10:53:16 +0100 message: Merge from mysql-5.6.15-release ------------------------------------------------------------ revno: 5583.2.2 tags: mysql-5.6.15 committer: Balasubramanian Kandasamy <balasubramanian.kandasamy@oracle.com> branch nick: mysql-5.6.15-release timestamp: Sun 2013-11-17 18:51:36 +0100 message: Merged Bug #17675622 cset 5632 from mysql-5.6 |