branches/5.0   bug#39483 InnoDB hang on adaptive hash because of out
of order ::open() call by MySQL

Under some conditions MySQL calls ::open with search_latch leading
to a deadlock as we try to acquire dict_sys->mutex inside ::open
breaking the latching order. The fix is to release search_latch.

Reviewed by: Heikki

This fixes Bug#36149: Read buffer overflow in srv0start.c found during "make
test"

Per-revision comments:

r2484 | vasil | 2008-05-28 15:32:48 +0300 (Wed, 28 May 2008) | 9 lines

Fix Bug#36149 Read buffer overflow in srv0start.c found during "make test"

Use strncmp(3) instead of memcmp(3) to avoid reading past end of the string
if it is empty (*str == '\0'). This bug is _not_ a buffer overflow.

Discussed with:	Sunny (via IM)

r2538 | inaam | 2008-07-15 21:24:02 +0300 (Tue, 15 Jul 2008) | 15 lines

Fix of issue# 4

Fixed a timing hole where a thread dropping an index can free the
in-memory index struct while another thread is still using
that structure to remove entries from adaptive hash index belonging
to one of the pages that belongs to the index being dropped.

The fix is to have a reference counter in the index struct and to
wait for this counter to drop to zero beforing freeing the struct.

Reviewed by: Heikki


r2544 | inaam | 2008-07-22 18:58:11 +0300 (Tue, 22 Jul 2008) | 8 lines

Removed UNIV_INLINE qualifier from btr_search_info_get_ref_count().
Otherwise compilation failed on non-debug builds.

Pointed by: Vasil

not handle errors from gettimeofday".

r2475 | vasil | 2008-05-22 19:35:30 +0300 (Thu, 22 May 2008) | 13 lines

Fix by retrying gettimeofday() several times if it fails in ut_usectime().
If it fails on all calls then return error to the caller to be handled
at higher level.

Update the variable innodb_row_lock_time_max in SHOW STATUS output only
if ut_usectime() was successful.

Bug#37671 crash on prepared statement + cursor + geometry + too many open files!
if mysql_execute_command() returns error then free materialized_cursor object.
is_rnd_inited is added to satisfy rnd_end() assertion
(handler may be uninitialized in some cases)

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.