The bug was repeated on MyISAM tables, so isn't InnoDB specific.
Reason of the bug is that partition-related members of TABLE_SHARE
wasn't properly updated after ALTER command. So if other thread doesn't
reread frm file, and just uses cached SHARE, it uses wrong data

  After merge fix.

into  moonbone.local:/mnt/gentoo64/work/test-5.1-opt-mysql

into  dl145s.mysql.com:/users/mhansson/mysql/autopush/mysql-5.0o-pushee

into  magare.gmz:/home/kgeorge/mysql/work/B28476-5.1-opt

Zero merge all except the new test

into  magare.gmz:/home/kgeorge/mysql/autopush/B28476-5.0-opt

When processing the USE/FORCE index hints
the optimizer was not checking if the indexes 
specified are enabled (see ALTER TABLE).
Fixed by:
 Backporting the fix for bug 20604 to 5.0

into  dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/mysql-5.0o-pushee

into  dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/mysql-5.1o-pushee

mode.

When a new DATE/DATETIME field without default value is being added by the
ALTER TABLE the '0000-00-00' value is used as the default one. But it wasn't
checked whether such value was allowed by the set sql mode. Due to this
'0000-00-00' values was allowed for DATE/DATETIME fields even in the
NO_ZERO_DATE mode.

Now the mysql_alter_table() function checks whether the '0000-00-00' value
is allowed for DATE/DATETIME fields by the set sql mode.
The new error_if_not_empty flag is used in the mysql_alter_table() function
to indicate that it should abort if the table being altered isn't empty.
The new new_datetime_field field is used in the mysql_alter_table() function
for error throwing purposes. 
The new error_if_not_empty parameter is added to the copy_data_between_tables()
function to indicate the it should return error if the source table isn't empty.

into  mysql.com:/home/hf/work/27984/my51-27984

into  mysql.com:/home/hf/work/27984/my51-27984

into  mysql.com:/home/hf/work/27984/my50-27984

into  mysql.com:/home/hf/work/27984/my50-27984

into  mysql.com:/home/hf/work/27984/my51-27984

into  mysql.com:/home/hf/work/27984/my51-27984

decimal_round failed to perform a correct rounding 
of a decimal number if its first nine digits were '9'.
It just sets those digits to 0.

into  mysql.com:/home/hf/work/28361/my50-28361

into  mysql.com:/home/hf/work/28361/my51-28361

into  dl145s.mysql.com:/users/mhansson/mysql/push/bug23856/my51-bug23856

into  mysql.com:/home/hf/work/27894/my50-27894

into  mysql.com:/home/hf/work/27894/my51-27894

into  mysql.com:/home/hf/work/27894/my51-27894

result max length changed for the 'decimal' fields
so test results have to be fixed

into  magare.gmz:/home/kgeorge/mysql/work/B22855-5.1-opt

into  magare.gmz:/home/kgeorge/mysql/work/B22855-5.0-opt

into  mysql.com:/home/hf/work/28361/my51-28361

my_decimal in some cases can contain more decimal digits than
is officially supported (DECIMAL_MAX_PRECISION), so we need to
prepare bigger buffer for the resulting string.

into  mysql.com:/d2/hf/mrg/mysql-5.1-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  sergbook.mysql.com:/usr/home/serg/Abk/mysql-5.0

into  mysql.com:/d2/hf/mrg/mysql-5.1-opt

into  mysql.com:/d2/hf/mrg/mysql-5.1-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt

into  mysql.com:/d2/hf/mrg/mysql-5.0-opt