rpl.rpl_trigger.test fails with valgrind errors with the innodb plugin

The problem is that there is only one autoinc value associated with 
the query when binlogging. If more than one autoinc values are used 
in the query, the autoinc values after the first one can be inserted 
wrongly on slave. So these autoinc values can become inconsistent on 
master and slave.

The problem is resolved by marking all the statements that invoke 
a trigger or call a function that updated autoinc fields as unsafe, 
and will switch to row-format in Mixed mode. Actually, the statement 
is safe if just one autoinc value is used in sub-statement, but it's 
impossible to check how many autoinc values are used in sub-statement.)

                    Removes the need of a hack (the jump to label).

On Mac OS X or Windows, sending a SIGHUP to the server or a
asynchronous flush (triggered by flush_time), would cause the
server to crash.

The problem was that a hook used to detach client API handles
wasn't prepared to handle cases where the thread does not have
a associated session.

The solution is to verify whether the thread has a associated
session before trying to detach a handle.

Make configure.js bail with an error if trying to build bdb from a bzr
tree.

Copy mysql-stress-run.pl into noinstall package.

          'flush tables' crashes

The server crashes when 'show procedure status' and 'flush tables' are
run concurrently.

This is caused by the way mysql.proc table is added twice to the list
of table to lock although the requirements on the current locking API
assumes differently.

No test case is submitted because of the nature of the crash which is 
currently difficult to reproduce in a deterministic way.

This is a backport from 5.1

The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the
database is not selected by --database option of mysqlbinlog command.
This can result in problem if there are some statements in the
transaction are not filtered out.

To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT' 
in regardless of the database filtering rules.

The 'BEGIN/COMMIT/ROLLBACK' log event could be filtered out if the
database is not selected by --database option of mysqlbinlog command.
This can result in problem if there are some statements in the
transaction are not filtered out.

To fix the problem, mysqlbinlog will output 'BEGIN/ROLLBACK/COMMIT' 
in regardless of the database filtering rules.

Backport from 6.0 to 5.1.
Only those sync points are included, which are used in debug_sync.test.

  The Debug Sync Facility allows to place synchronization points
  in the code:
  
  open_tables(...)
  
  DEBUG_SYNC(thd, "after_open_tables");
  
  lock_tables(...)
  
  When activated, a sync point can
  
  - Send a signal and/or
  - Wait for a signal
  
  Nomenclature:
  
  - signal:            A value of a global variable that persists
                       until overwritten by a new signal. The global
                       variable can also be seen as a "signal post"
                       or "flag mast". Then the signal is what is
                       attached to the "signal post" or "flag mast".
  
  - send a signal:     Assign the value (the signal) to the global
                       variable ("set a flag") and broadcast a
                       global condition to wake those waiting for
                       a signal.
  
  - wait for a signal: Loop over waiting for the global condition until
                       the global value matches the wait-for signal.
  
  Please find more information in the top comment in debug_sync.cc
  or in the worklog entry.

          replication
              
MySQL server uses wrong lock type (always TL_READ instead of
TL_READ_NO_INSERT when appropriate) for tables used in
subqueries of UPDATE statement. This leads in some cases to
a broken replication as statements are written in the wrong
order to the binlog.

can be interpreted as a shell metacharacter in some circumstances.
For example, it is interpreted as a command separator when invoking
a debugger.

The problem was that appending values to the end of an existing
ENUM or SET column was being treated as table data modification,
preventing a immediately (fast) table alteration that occurs when
only table metadata is being modified.

The cause was twofold: adding a enumeration or set members to the 
end of the list of valid member values was not being considered
a "compatible" table alteration, and for SET columns, the check
was being done upon the max display length and not the underlying
(pack) length of the field.

The solution is to augment the function that checks wether two ENUM
or SET fields are compatible -- by comparing the pack lengths and
performing a limited comparison of the member values.

The bug is not related to MERGE table or TRIGGER. More correct description
would be 'assertion on multi-table UPDATE + NATURAL JOIN + MERGEABLE VIEW'.
On PREPARE stage(see test case) we call mark_common_columns() func which
creates ON condition for NATURAL JOIN and sets appropriate
table read_set bitmaps for fields which are used in ON condition.
On EXECUTE stage mark_common_columns() is not called, we set
necessary read_set bitmaps in setup_conds(). But 'B.f1' field
is already processed and related item alredy fixed before
setup_conds() as updated field and setup_conds can not set
read_set bitmap because of that.
The fix is to set read_set bitmap for appropriate table field even
if Item_direct_view_ref item which represents a refernce to this field
is fixed.