This is a merge from 5.1/builtin to 5.1/plugin of:

  --------------
  revision-id: vasil.dimov@oracle.com-20101018104811-nwqhg9vav17kl5s1
  committer: Vasil Dimov <vasil.dimov@oracle.com>
  timestamp: Mon 2010-10-18 13:48:11 +0300
  message:
    Fix Bug#57252 disabling innobase_stats_on_metadata disables ANALYZE
    
    In order to fix this bug we need to distinguish whether ha_innobase::info()
    has been called from ::analyze() or not. Rename ::info() to ::info_low()
    and add a boolean parameter that tells whether the call is from ::analyze()
    or not. Create a new simple ::info() that just calls
    ::info_low(false => not called from analyze). From ::analyze() instead of
    ::info() call ::info_low(true => called from analyze).
    
    Approved by:	Jimmy (rb://487)
  --------------

In order to fix this bug we need to distinguish whether ha_innobase::info()
has been called from ::analyze() or not. Rename ::info() to ::info_low()
and add a boolean parameter that tells whether the call is from ::analyze()
or not. Create a new simple ::info() that just calls
::info_low(false => not called from analyze). From ::analyze() instead of
::info() call ::info_low(true => called from analyze).

Approved by:	Jimmy (rb://487)

It was added in jimmy.yang@oracle.com-20100902004302-m5ax9qo0ne2msdfx

Tune the test for Bug#56143 too many foreign keys causes output of show create table to become invalid

Use a CREATE statement with all the FKs instead of ALTERing the table many
times because it is faster (11 seconds vs 3 seconds).

This is a port of the following changeset from
5.1/storage/innobase to 5.1/storage/innodb_plugin:

  ------------------------------------------------------------
  revno: 3626
  revision-id: vasil.dimov@oracle.com-20101013171859-gi9n558yj89x9v3w
  parent: klewis@mysql.com-20101012175933-ce9kkgl0z8oeqffa
  committer: Vasil Dimov <vasil.dimov@oracle.com>
  branch nick: mysql-5.1-innodb
  timestamp: Wed 2010-10-13 20:18:59 +0300
  message:
    Fix Bug#56143 too many foreign keys causes output of show create table to become invalid
    
    Just remove the check whether the file is "too big".
    A similar code exists in ha_innobase::update_table_comment() but that
    method does not seem to be used.

Also use a CREATE statement with all the FKs instead of ALTERing the
table 550 times because it is faster.

Just remove the check whether the file is "too big".
A similar code exists in ha_innobase::update_table_comment() but that
method does not seem to be used.

rb://483 approved by Inaam

latest mysql-5.1-bugteam.

latest mysql-5.1-bugteam.

Bug#56632 - The warning code related to KEY_BLOCK_SIZE and ROW_FORMAT  when innodb_strict_mode=OFF  is improved in order to take into account whether the KEY_BLOCK_SIZE is specified on the current ALTER statement or the previous CREATE statement.
    
The testcase shows the expected results of 12 different combinations of these settings.

with concurrent lock/unlock tables

Approved by Marko

After ALTER TABLE which changed only table's metadata, row-based
binlog sometimes got corrupted since the tablemap was unexpectedly
set to 0 for subsequent updates to the same table.

ALTER TABLE which changed only table's metadata always reset
table_map_id for the table share to 0. Despite the fact that
0 is a valid value for table_map_id, this step caused problems
as it could have created situation in which we had more than
one table share with table_map_id equal 0. If more than one
table with table_map_id are 0 were updated in the same statement,
updates to these different tables were written into the same
rows event. This caused slave server to crash.

This bug happens only on 5.1. It doesn't affect 5.5+.

This patch solves this problem by ensuring that ALTER TABLE
statements which change metadata only never reset table_map_id
to 0. To do this it changes reopen_table() to correctly use
refreshed table_map_id value instead of using the old one/
resetting it.

Print an error message to stderr an get rid of the assertion.

Approved by: Jimmy Yang (over IM)

When slave executes a transaction bigger than slave's max_binlog_cache_size,
slave will crash. It is caused by the assert that server should only roll back
the statement but not the whole transaction if the error ER_TRANS_CACHE_FULL 
happens. But slave sql thread always rollbacks the whole transaction when
an error happens.
            
Ather this patch, we always clear any error set in sql thread(it is different
from the error in 'SHOW SLAVE STATUS') and it is cleared before rolling back
the transaction.

This is a regression from the fix for bug no 38999. A storage engine capable
of reading only a subset of a table's columns updates corresponding bits in
the read buffer to signal that it has read NULL values for the corresponding
columns. It cannot, and should not, update any other bits. Bug no 38999
occurred because the implementation of UPDATE statements compare the NULL bits
using memcmp, inadvertently comparing bits that were never requested from the
storage engine. The regression was caused by the storage engine trying to
alleviate the situation by writing to all NULL bits, even those that it had no
knowledge of. This has devastating effects for the index merge algorithm,
which relies on all NULL bits, except those explicitly requested, being left
unchanged.

The fix reverts the fix for bug no 38999 in both InnoDB and InnoDB plugin and
changes the server's method of comparing records. For engines that always read
entire rows, we proceed as usual. For engines capable of reading only select
columns, the record buffers are now compared on a column by column basis. An
assertion was also added so that non comparable buffers are never read. Some
relevant copy-pasted code was also consolidated in a new function.

      
Suprisingly, a Slave_log_event would show up in the binary
log. This event is never used and should not appear in the
logs. As such, when the slave (or the mysqlbinlog tool) reads the
event, it will hit an invalid pointer (reference to the
descriptor event when deserializing the Slave_log_event was
purposodely set to NULL).
      
The presence of the Slave_log_event denotes a corrupted log, but
we cannot tell how the log got corrupted in the first
place. However, we can make the server cope with such events when
it reads them - in case of log corruption - and fail gracefully.
     
This patch makes the server/mysqlbinlog to report that it has
found an invalid log event when Slave_log_event is read.

Backported the patch for BUG#55452.

row_search_for_mysql(): Acquire an intention lock on the table
before locking the first record gap.

row_search_for_mysql(): Acquire an intention lock on the table
before locking the first record gap.