| Server IP : 180.180.241.3 / Your IP : 216.73.216.216 Web Server : Microsoft-IIS/7.5 System : Windows NT NETWORK-NHRC 6.1 build 7601 (Windows Server 2008 R2 Standard Edition Service Pack 1) i586 User : IUSR ( 0) PHP Version : 5.3.28 Disable Function : NONE MySQL : ON | cURL : ON | WGET : OFF | Perl : OFF | Python : OFF | Sudo : OFF | Pkexec : OFF Directory : C:/Program Files/MySQL/MySQL Server 5.6/docs/ |
Upload File : |
------------------------------------------------------------
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