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.

mysql-test/suite/rpl/t/rpl_row_create_table.test:
  Removing positions from SHOW BINLOG EVENTS and using
  reset_master_and_slave to start on a fresh binary log each time.
mysql-test/suite/rpl/t/rpl_slave_skip.test:
  Adding explicit commit in AUTOCOMMIT=0 to make test work correctly.
mysql-test/suite/rpl/t/rpl_trigger.test:
  Adding test case for BUG#40116.
sql/log.cc:
  Changing commit logic in binlog_commit() to only commit when
  committing a real transaction or committing a punch transaction.

Adding missing drop of created table and tidying display.


mysql-test/t/innodb_mysql.test:
  Adding drop of created table and cleaning variable 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.

mysql-test/t/innodb_mysql.test:
  Adding test that no error message is printed from inside
  InnoDB when the binary log is turned off.

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.


mysql-test/r/alter_table.result:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - test result.
mysql-test/t/alter_table.test:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - test case.
sql/field.cc:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - Field_enum::is_equal() introduced, which is called to detect that a field
  is changing by 'ALTER TABLE'.
sql/field.h:
  Fix for bug#23113: Different behavior on altering ENUM fields between 5.0 and 5.1
    - Field_enum::is_equal() introduced, which is called to detect that a field
  is changing by 'ALTER TABLE'.

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

mysql-test/t/binlog_format_basic.test:
  Added test case to verify the default binlog_format: it should be
  STATEMENT in 5.1 and MIXED in 6.0.

mysql-test/r/xa.result:
  Update test case result.
mysql-test/t/xa.test:
  Drop table used for test.

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.

mysql-test/r/xa.result:
  Add test case result for Bug#28323
mysql-test/t/xa.test:
  Add test case for Bug#28323
sql/handler.cc:
  Reset XID only at the end of the global transaction.
sql/share/errmsg.txt:
  Add new error codes.
sql/sql_class.h:
  Remember the error reported by the Resource Manager.
sql/sql_parse.cc:
  Rollback the transaction if the Resource Manager reported
  a error and 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.


sql/handler.cc:
    - check for incompatible collation changes made in 5.1.24-rc:
  bug #27877:
    utf8_general_ci
    ucs2_general_ci

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.


mysql-test/r/lock_multi.result:
  Added test case for bug #38499.
mysql-test/t/lock_multi.test:
  Added test case for bug #38499.
sql/sql_union.cc:
  Bug#38499: flush tables and multitable table update with
             derived table cause crash
  
  Obsolete assertion has been removed.
sql/sql_update.cc:
  Bug#38499: flush tables and multitable table update with
             derived table cause crash
  
  Extra cleanup for derived tables has been added:
  1) unit.cleanup(),
  2) unit->reinit_exec_mechanism().

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.


sql/handler.cc:
  Fix for bug#39585: innodb and myisam corruption after binary 
  upgrade from <=5.0.46 to >=5.0.48
    - check for incompatible collation changes made in 5.0.48:
  bug #29461
    latin7_general_ci
    latin7_general_cs
    latin7_estonian_cs
    latin2_hungarian_ci
    koi8u_general_ci
    cp1251_ukrainian_ci
    cp1250_general_ci
  bug #29499, bug #27562
    ascii_general_ci

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.

mysql-test/suite/rpl/t/rpl_row_create_table.test:
  Added test to check that CREATE-SELECT into another database than the
  current one replicates.
sql/sql_insert.cc:
  Adding parameter to calls to store_create_info().
sql/sql_show.cc:
  Adding parameter to calls to store_create_info().
  
  Extending store_create_info() with parameter 'show_database' that will cause
  the database to be written before the table name.
sql/sql_show.h:
  Adding parameter to call to store_create_info() to tell if the database should be shown or not.
sql/sql_table.cc:
  Adding parameter to calls to store_create_info().

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.

sql/handler.h:
  Bug#37453: Dropping/creating index on partitioned table with
  InnoDB Plugin locks table
  
  The check for which alter table flags a handler have is done through the
  handlerton, which will not work correctly for any partitioned table.
  It must be through the handler interface.
  
  To be able to fix this I have to add a virtual function to the handler class.

          ``FLUSH TABLES WITH READ LOCK''

Concurrent execution of 1) multitable update with a
NATURAL/USING join and 2) a such query as "FLUSH TABLES
WITH READ LOCK" or "ALTER TABLE" of updating table led
to a server crash.


The mysql_multi_update_prepare() function call is optimized
to lock updating tables only, so it postpones locking to
the last, and if locking fails, it does cleanup of modified
syntax structures and repeats a query analysis.  However,
that cleanup procedure was incomplete for NATURAL/USING join
syntax data: 1) some Field_item items pointed into freed
table structures, and 2) the TABLE_LIST::join_columns fields
was not reset.

Major change:
  short-living Field *Natural_join_column::table_field has
  been replaced with long-living Item*.


mysql-test/r/lock_multi.result:
  Added test case for bug #38691.
mysql-test/t/lock_multi.test:
  Added test case for bug #38691.
sql/item.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  The Item_field constructor has been modified to allocate
  and copy original database/table/field names always (not
  during PS preparation/1st execution only), because
  an initialization of Item_field items with a pointer to
  short-living Field structures is a common practice.
sql/sql_base.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  1) Type adjustment for Natural_join_column::table_field
     (Field to Item_field);
  2) The setup_natural_join_row_types function has been
     updated to take into account new
     first_natural_join_processing flag to skip unnecessary
     reinitialization of Natural_join_column::join_columns
     during table reopening after lock_tables() failure
     (like the 'first_execution' flag for PS).
sql/sql_lex.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Initialization of the new
  st_select_lex::first_natural_join_processing flag has
  been added.
sql/sql_lex.h:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  The st_select_lex::first_natural_join_processing flag
  has been added to skip unnecessary rebuilding of
  NATURAL/USING JOIN structures during table reopening
  after lock_tables failure.
sql/sql_update.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Extra cleanup calls have been added to reset
  Natural_join_column::table_field items.
sql/table.cc:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Type adjustment for Natural_join_column::table_field
  (Field to Item_field).
sql/table.h:
  Bug #38691: segfault/abort in ``UPDATE ...JOIN'' while
            ``FLUSH TABLES WITH READ LOCK''
  
  Type of the Natural_join_column::table_field field has
  been changed from Field that points into short-living
  TABLE memory to long-living Item_field that can be
  linked to (fixed) reopened table.