Removed values with more than 15 significant digits from the test case. Results of 
reading/printing such values using system library functions depend on implementation 
and thus are not portable.

if table has bit fields then uneven bits(if exist) are stored into null bits place.
So we need to copy null bits in case of uneven bit field presence.

added ability for TINY[MEDIUM] text fields 
to be converted to greater subtype during
alter if necessary(altered charset)

the patch manually to another tree. 

the problem: FORMAT func max_length value was calculated incorrectly
the fix: correct calculation of max_length

show default value for BIT field in printable format

The reason for the failures was bug #21205 (fixed in 6.0 by dtoa, but still present in 5.0/5.1).

Altered how we copy data from mysql-test/std_data on Windows to match what we are doing in 5.1 and 6.0

Bug #41173 rpl_packet fails sporadically on pushbuild: query 'DROP TABLE t1' failed


The both issues appeared to be a race between the SQL thread executing CREATE table t1
and the IO thread that is expected to stop at the consequent big size event.
The two events need serialization which is implemented.
The early bug required back-porting a part fixes for bug#38350 exclusively for 5.0 version.

BUG#39325 Server crash inside MYSQL_LOG::purge_first_log halts replicaiton

The patch reverses the order of the purging and updating events for log and relay-log.info/index files respectively.
This solves the problem of having holes caused by crashes happening between updating info/index files and purging logs.

NOTE: This is a combined patch for BUG#38826 and BUG#39325. This patch is based on bugteam tree and takes into account reviewers suggestions.

                    bigint' fails on windows.

Visual Studio does not take into account some x86 hardware limitations
which leads to incorrect results when converting large DOUBLE values
to BIGINT UNSIGNED ones.

Fixed by adding a workaround for double->ulonglong conversion on
Windows.

                  
Updated MySQL time handling code to react correctly on UTC leap second additions.
MySQL functions that return the OS current time, like e.g. CURDATE(), NOW() etc
will return :59:59 instead of :59:60 or 59:61.
As a result the reader will receive :59:59 for 2 or 3 consecutive seconds 
during the leap second.
This fix will not affect the values returned by UNIX_TIMESTAMP() for leap seconds.
But note that when converting the value returned by UNIX_TIMESTAMP() to broken 
down time the correction of leap seconds will still be applied.
Note that this fix will make a difference *only* if the OS is specially configured
to return leap seconds from the OS time calls or when using a MySQL time zone 
defintion that has leap seconds.
Even after this change date/time literals (or other broken down time 
representations) with leap seconds (ending on :59:60 or 59:61) will still be 
considered illegal and discarded by the server with an error or 
a warning depending on the sql mode.
Added a test case to demonstrate the effect of the fix.

by using and taking out a full path.

TABLE_LIST doesn't free Strings in its string lists
(TABLE_LIST::use_index and TABLE_liST::ignore_index), so
calling c_ptr_safe() on that Strings leads to memleaks.
OTOH "safe" c_ptr_safe() is not necessary there and we can
replace it with c_ptr().

Diff to actual 5.0-bugteam is revno: 2725 only

            an error

Even after the fix for bug 28701 visible behaviors of
SELECT FROM a view and SELECT FROM a regular table are
little bit different:

1. "SELECT FROM regular table USE/FORCE/IGNORE(non
   existent index)" fails with a "ERROR 1176 (HY000):
   Key '...' doesn't exist in table '...'"

2. "SELECT FROM view USING/FORCE/IGNORE(any index)" fails
   with a "ERROR 1221 (HY000): Incorrect usage of
   USE/IGNORE INDEX and VIEW".  OTOH "SHOW INDEX FROM
   view" always returns empty result set, so from the point
   of same behaviour view we trying to use/ignore non
   existent index.

To harmonize the behaviour of USE/FORCE/IGNORE(index)
clauses in SELECT from a view and from a regular table the
"ERROR 1221 (HY000): Incorrect usage of USE/IGNORE INDEX
and VIEW" message has been replaced with the "ERROR 1176
(HY000): Key '...' doesn't exist in table '...'" message
like for tables and non existent keys.

      
The SHOW VARIABLES LIKE .../SELECT @@/SELECT ... FROM INFORMATION_SCHEMA.VARIABLES
were assuming that all the system variables are in system charset (UTF-8).
However the variables that are settable through command line will have a different
character set (character_set_filesystem).
Fixed the server to remember the correct character set of basedir, datadir, tmpdir,
ssl, plugin_dir, slave_load_tmpdir, innodb variables; init_connect and init_slave 
variables and use it when processing data.

Certain boolean mode queries with truncation operator did
not return matching records and calculate relevancy
incorrectly.