Uncommited changes are replicated and stay on slave after
rollback on master

Making test slightly more generic and robust.

after rollback on master

When starting a transaction with a statement containing changes
to both transactional tables and non-transactional tables, the
statement is considered as non-transactional and is therefore
written directly to the binary log. This behaviour was present
in 5.0, and has propagated to 5.1.

If a trigger containing a change of a non-transactional table is
added to a transactional table, any changes to the transactional
table is "tainted" as non-transactional.

This patch solves the problem by removing the existing "hack" that
allows non-transactional statements appearing first in a transaction
to be written directly to the binary log. Instead, anything inside
a transaction is treaded as part of the transaction and not written
to the binary log until the transaction is committed.

Adding missing drop of created table and tidying display.

      
When statement-based replication is used, and the
transaction isolation level is READ-COMMITTED or stricter,
InnoDB will print an error because statement-based
replication might lead to inconsistency between master
and slave databases. However, when the binary log is not
engaged, this is not an issue and an error should
not be printed.

This patch makes thd_binlog_format() return BINLOG_FORMAT_
UNSPEC when the binary log is not engaged for the given
thread.

Adding comments to test cases.

Problem: mysqld doesn't detect that enum data must be reinserted performing
'ALTER TABLE' in some cases.

Fix: reinsert data altering an enum field if enum values are changed.

Added test case to check the default value of @@binlog_format.

The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.

The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.

            
Debug builds of MySQL 5.1, 6.0 with Sun Studio 12 broke because of
use of gcc specific feature.
            
The fix is to replace __FUNCTION__ with the corresponding character string

In certain situations, a scan of the table will return the error
code HA_ERR_RECORD_DELETED, and this error code is not 
correctly caught in the Rows_log_event::find_row() function, which
causes an error to be returned for this case.

This patch fixes the problem by adding code to either ignore the
record and continuing with the next one, the the event of a table
scan, or change the error code to HA_ERR_KEY_NOT_FOUND, in the event
that a key lookup is attempted.

collation change made in 5.1.24-rc

Problem: 'CHECK TABLE ... FOR UPGRADE' did not check for 
incompatible collation changes made in MySQL 5.1.24-rc.

Fix: add the check.

This time the inclusion of <stdio.h> before "config.h" enabled legacy large
file support, seek64() and similar, on AIX breaking the compile of "gzio.c"

Merge conflicts in test "create:
- for "create.result", handled correctly by "bzr extmerge" (using "kdiff3"),
- for "create.test", not reported as a conflict, but merged wrong
  (new block at the test end got duplicated), fixed manually.

Test on Linux (Debian, PowerPC) was ok.

           derived table cause crash

When a multi-UPDATE command fails to lock some table, and
subsequently succeeds, the tables need to be reopened if
they were altered. But the reopening procedure failed for
derived tables.

Extra cleanup has been added.

Fixed a compilation warning

upgrade from <=5.0.46 to >=5.0.48

Problem: 'check table .. for upgrade' doesn't detect 
incompatible collation changes made in 5.0.48.

Fix: check for incompatible collation changes.

The failure was caused by executing a CREATE-SELECT statement that creates a
table in another database than the current one. In row-based logging, the
CREATE statement was written to the binary log without the database, hence
creating the table in the wrong database, causing the following inserts to
fail since the table didn't exist in the given database.

Fixed the bug by adding a parameter to store_create_info() that will make
the function print the database name before the table name and used that
in the calls that write the CREATE statement to the binary log. The database
name is only printed if it is different than the currently selected database.

The output of SHOW CREATE TABLE has not changed and is still printed without
the database name.

disabled a randomly failing test and opened a bug report

InnoDB Plugin locks table

This is a pre fix update that does the change to the handler api.

This is done since there are already changes in this version,
so the real fix does not need to change the api.