UNION could convert fixed-point FLOAT(M,D)/DOUBLE(M,D) columns  
to FLOAT/DOUBLE when aggregating data types from the SELECT  
substatements. While there is nothing particularly wrong with  
this behavior, especially when M is greater than the hardware  
precision limits, it could be confusing in cases when all  
SELECT statements in a union have the same  
FLOAT(M,D)/DOUBLE(M,D) columns with equal precision  
specifications listed in the same position.  
  
Since the manual is quite vague on what data type should be  
returned in such cases, the bug was fixed by implementing the  
most 'expected' behavior: do not convert FLOAT(M,D)/DOUBLE(M,D)  
to anything else if all SELECT statements in a UNION have the  
same precision for that column.  

mysql-test/r/union.result:
  Added a test case for bug #43432.
mysql-test/t/union.test:
  Added a test case for bug #43432.
sql/field.cc:
  Replaced FLT_DIG+6 and DBL_DIG+7 with a symbolic constant.
sql/item.cc:
  Do not convert FLOAT(M,D)/DOUBLE(M,D) 
  to anything else if all SELECT statements in a UNION have the 
  same precision for that column.
sql/mysql_priv.h:
  Added a symbolic constant for FLT_DIG+6 and DBL_DIG+7.

Problem: commit doesn't delete savepoints if there are no changes 
in the transaction.

Fix: delete them in such cases.


mysql-test/r/innodb_mysql.result:
  Fix for bug #26288: savepoint not deleted, comit on empty transaction
    - test result.
mysql-test/t/innodb_mysql.test:
  Fix for bug #26288: savepoint not deleted, comit on empty transaction
    - test case.
sql/handler.cc:
  Fix for bug #26288: savepoint not deleted, comit on empty transaction
    - call transaction.cleanup() even if nht is 0 to delete 
  possible savepoints.

The problem is that the read and write methods of the shared
memory transport (protocol) didn't react to asynchornous close
events, which could lead to a lock up as the client would wait
(until time out) for a server response that will never come.

The solution is to also wait for close events while waiting
for I/O from or to the server.

Bug report and patch submitted by: Armin Schöffmann

The problem is that the read and write methods of the shared
memory transport (protocol) didn't react to asynchronous close
events, which could lead to a lock up as the client would wait
(until time out) for a server response that will never come.

The solution is to also wait for close events while waiting
for I/O from or to the server.

mysql-test/r/shm.result:
  Add test case result for Bug#33899
mysql-test/t/shm.test:
  Add test case for Bug#33899
vio/viosocket.c:
  Also wait for close events.

      
When add an aliase name after NAME_CONST, the aliase name will be overwrite.
      
NAME_CONST will re-set the field's name only if there isn't an aliase in the
function fix-fields().
If there is an aliase, NAME_CONST doesn't re-set the field's name and keeps the old
name.

mysql-test/r/func_misc.result:
  Test result.
mysql-test/r/rpl_name_const.result:
  Test case.
mysql-test/t/func_misc.test:
  Add NAME_CONST test.
mysql-test/t/rpl_name_const.test:
  Test result.
sql/item.cc:
  Re-set field's name if the name is autogenerated, that mean without aliase.

            
After the table is compressed by the myisampack utility,
opening the table by the server produces valgrind warnings.
      
This happens because when we try to read a record into the buffer
we alway assume that the remaining buffer to read is always equal 
to word size(4 or 8 or 2 bytes) we read. Sometimes we have 
remaining buffer size less than word size and trying to read the 
entire word size will end up in valgrind errors.
            
Fixed by reading byte by byte when we detect the remaining buffer 
size is less than the word size.

myisam/mi_packrec.c:
  Fixed fill_buffer() to read byte by byte when the remaining 
  buffer size is less than word size.
mysql-test/r/myisampack.result:
  Result file for BUG#41541
mysql-test/t/myisampack.test:
  Testcase for BUG#41541

                    expired timeout on debx86-b in PB

Turned off general log when importing DB dump in the test 
case for bug #41486 due to the bug in CSV engine code that 
makes logging long SQL query too slow.

mysql-test/r/mysql-bug41486.result:
  Turned off general log when importing DB dump in the test 
  case for bug #41486 due to the bug in CSV engine code that 
  makes logging long SQL query too slow.
mysql-test/t/mysql-bug41486.test:
  Turned off general log when importing DB dump in the test 
  case for bug #41486 due to the bug in CSV engine code that 
  makes logging long SQL query too slow.

Reset master before next test.

mysql-test/suite/rpl/r/rpl_timezone.result:
  Test result.
mysql-test/suite/rpl/t/rpl_timezone.test:
  Reset master before next test.

                    expired timeout on debx86-b in PB 

Moved the resource-intensive test case for bug #41486 into 
a separate test file to reduce execution time for mysql.test. 


mysql-test/include/wait_until_disconnected.inc:
  Used in mysql-bug41486.test.
mysql-test/r/mysql-bug41486.result:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/r/mysql.result:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/t/mysql-bug41486.test:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.
mysql-test/t/mysql.test:
  Moved the resource-intensive test case for bug #41486 into 
  a separate test file to reduce execution time for mysql.test.

LOAD_FILE
            
LOAD_FILE is not safe to replicate in STATEMENT mode, because it
depends on a file (which is loaded on master and may not exist in
slave(s)). This leads to scenarios on which the slave replicates the
statement with 'load_file' and it will try to load the file from local
file system. Given that the file may not exist in the slave filesystem
the operation will not succeed (probably returning NULL), causing
master and slave(s) to diverge. However, when using MIXED mode
replication, this can be made to work, if the statement including
LOAD_FILE is marked as unsafe, triggering a switch to ROW mode,
meaning that the contents of the file are written to binlog as row
events. Consequently, the contents from the file in the master will
reach the slave via the binlog.
           
This patch addresses this bug by marking the load_file function as
unsafe. When in mixed mode and when LOAD_FILE is issued, there will be
a switch to row mode. Furthermore, when in statement mode, the
LOAD_FILE will raise a warning that the statement is unsafe in that
mode.


mysql-test/extra/rpl_tests/rpl_loadfile.test:
  Extra file that is "sourced" on both rpl_loadfile and rpl_stm_loadfile
  test files.
mysql-test/suite/rpl/r/rpl_loadfile.result:
  Updated with the results from the test case added to this file.
mysql-test/suite/rpl/r/rpl_stm_loadfile.result:
  Result file for rpl_loadfile test split with the warnings in statement
  mode.
mysql-test/suite/rpl/t/rpl_loadfile.test:
  After splitting the original rpl_loadfile file, this one is only 
  required to be executed in mixed or row format.
  Appended the test for 39701 to this file.
mysql-test/suite/rpl/t/rpl_stm_loadfile.test:
  Split the original rpl_loadfile test because load_file now raises
  a warning when in statement mode. The goal of this split is 
  two-fold: i) make the test case more resilient; ii) assert that 
  warnings are indeed raised when in statement mode.
sql/item_create.cc:
  Added the set_stmt_unsafe call to lex.