they are ignored to a new test suite "innodb_plugin".

Remove a hack in mtr that was deployed to run the builtin InnoDB tests against
the InnoDB Plugin. Also detect if a test is an 'innodb plugin test' and if so
then transparently replace the builtin InnoDB with the InnoDB Plugin.

in behavior in InnoDB. The change in behavior was introduced by this
changeset:

  ------------------------------------------------------------
  revno: 3370
  revision-id: vasil.dimov@oracle.com-20100331130613-8ja7n0vh36a80457
  parent: vasil.dimov@oracle.com-20100331130440-l0y517y3mjsjqy4v
  parent: vasil.dimov@oracle.com-20100331113119-2kbgkaz1d426a43c
  committer: Vasil Dimov <vasil.dimov@oracle.com>
  branch nick: mysql-5.1-innodb
  timestamp: Wed 2010-03-31 16:06:13 +0300
  message:
    Merge from innodb-branches-5.1
      ------------------------------------------------------------
      revno: 0.1.819
      revision-id: vasil.dimov@oracle.com-20100331113119-2kbgkaz1d426a43c
      parent: vasil.dimov@oracle.com-20100331064722-9rc3wypzmer7d6jj
      parent: svn-v4:cee13dc7-1704-0410-992b-c9b4543f1246:branches/5.1:6918
      committer: Vasil Dimov <vasil.dimov@oracle.com>
      branch nick: innodb-branches-5.1
      timestamp: Wed 2010-03-31 14:31:19 +0300
      message:
        Merge from SVN
          ------------------------------------------------------------
          revno: 0.2.1
          revision-id: svn-v4:cee13dc7-1704-0410-992b-c9b4543f1246:branches/5.1:6918
          parent: svn-v4:cee13dc7-1704-0410-992b-c9b4543f1246:branches/5.1:6912
          committer: mmakela
          timestamp: Wed 2010-03-31 07:14:51 +0000
          message:
            branches/5.1: Obey KILL during a lock wait (Bug #51920).
  
            srv_suspend_mysql_thread(), srv_lock_timeout_and_monitor_thread():
            Check trx_is_interrupted() in addition to checking the lock wait timeout.
  
            rb://279 approved by Sunny Bains

Repply changes to storage/innodb_plugin/mysql-test/innodb_bug42101-nonzero-master.opt that were made by MySQL

Move ut_ad() to after declarations for C file.

about wrong innodb_change_buffering value.  Reported by Ranger.

Stick to C90, because some build platforms are not C99 yet.

Fix ./export.sh to honor ENDREV

dict_table_check_for_dup_indexes(): Add the flag tmp_ok.  If !tmp_ok,
check that no index name starts with TEMP_INDEX_PREFIX.

ha_innobase::add_index(), ha_innobase::prepare_drop_index(),
ha_innobase::final_drop_index(): Call dict_table_check_for_dup_indexes().

The problem is that we can not use make_cond_for_table().
This function relies on used_tables() condition
which is not set properly for subqueries.
As result subquery is not filtered out.
The fix is to use remove_eq_conds() function instead
of make_cond_for_table() func. 'remove_eq_conds()'
algorithm relies on const_item() value and it allows
to handle subqueries in right way.

            Procedure, while DECIMAL works

Selecting of the CONCAT(...<SP variable>...) result into
a user variable may return wrong data.


Item_func_concat::val_str contains a number of memory
allocation-saving tricks. One of them concatenates
strings inplace inserting the value of one string
at the beginning of the other string. However,
this trick didn't care about strings those points
to the same data buffer: this is possible when
a CONCAT() parameter is a stored procedure variable -
Item_sp_variable::val_str() uses the intermediate
Item_sp_variable::str_value field, where it may
store a reference to an external buffer.


The Item_func_concat::val_str function has been
modified to take into account val_str functions
(such as Item_sp_variable::val_str) that return
a pointer to an internal Item member variable
that may reference to a buffer provided.

       on index

'my_decimal' class has two members which can be used to access the 
value. The member variable buf (inherited from parent class decimal_t) 
is set to member variable buffer so that both are pointing to same value.

Item_copy_decimal::copy() uses memcpy to clone 'my_decimal'. The member
buffer is declared as an array and memcpy results in copying the values
of the array, but the inherited member buf, which should be pointing at
the begining of the array 'buffer' starts pointing to the begining of 
buffer in original object (which is being cloned). Further updates on 
'my_decimal' updates only the inherited member 'buf' but leaves 
buffer unchanged.

Later when the new object (which now holds a inconsistent value) is cloned
again using proper cloning function 'my_decimal2decimal' the buf pointer
is fixed resulting in loss of the current value.

Using my_decimal2decimal instead of memcpy in Item_copy_decimal::copy()
fixed this problem.

            data and index files

It was possible if DATA/INDEX DIRECTORY is pointing to
symlinked MySQL data home directory.

Do not allow to drop data/index files implicitly symlinked
to data home directory. For such tables remove symlink only.

Detailed revision comments:

r6900 | mmakela | 2010-03-29 13:54:57 +0300 (Mon, 29 Mar 2010) | 5 lines
branches/zip: Merge c6899 from branches/innodb+:

Add debug assertions to track down Bug #52360.
hash_table_t::magic_n: Add HASH_TABLE_MAGIC_N checks, which were fully absent.
ut_hash_ulint(): Assert table_size > 0 before division.

Detailed revision comments:

r6897 | mmakela | 2010-03-29 11:36:19 +0300 (Mon, 29 Mar 2010) | 3 lines
branches/zip: innodb_mutex_show_status(): Fix a condition
that was accidentally negated in r6781, making SHOW ENGINE INNODB MUTEX STATUS
display only locks with no OS waits.