SELECT ... WHERE ... IN (NULL, ...) does full table scan,
even if the same query without the NULL uses efficient range scan.

The bugfix for the bug 18360 introduced an optimization:
if
  1) all right-hand arguments of the IN function are constants
  2) result types of all right argument items are compatible
     enough to use the same single comparison function to
     compare all of them to the left argument,

then

  we can convert the right-hand list of constant items to an array
  of equally-typed constant values for the further
  QUICK index access etc. (see Item_func_in::fix_length_and_dec()).

The Item_null constant item objects have STRING_RESULT
result types, so, as far as Item_func_in::fix_length_and_dec()
is aware of NULLs in the right list, this improvement efficiently
optimizes IN function calls with a mixed right list of NULLs and
string constants. However, the optimization doesn't affect mixed
lists of NULLs and integers, floats etc., because there is no
unique common comparator.


New optimization has been added to ignore the result type
of NULL constants in the static analysis of mixed right-hand lists.
This is safe, because at the execution phase we care about
presence of NULLs anyway.

1. The collect_cmp_types() function has been modified to optionally
   ignore NULL constants in the item list.
2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
   function has been modified to work not only with in_string
   vectors but with in_vectors of other types.


mysql-test/r/func_in.result:
  Added test case for the bug #44139.
mysql-test/t/func_in.test:
  Added test case for the bug #44139.
sql/item_cmpfunc.cc:
  Bug #44139: Table scan when NULL appears in IN clause
  
  1. The collect_cmp_types() function has been modified to optionally
     ignore NULL constants in the item list.
  2. NULL-skipping code of the Item_func_in::fix_length_and_dec()
     function has been modified to work not only with in_string
     vectors but with in_vectors of other types.

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.)

mysql-test/suite/rpl/r/rpl_auto_increment_update_failure.result:
  Test result for bug#45677
mysql-test/suite/rpl/t/rpl_auto_increment_update_failure.test:
  Added test to verify the following two properties:
  P1) insert/update in an autoinc column causes statement to 
  be logged in row format if binlog_format=mixed
  P2) if binlog_format=mixed, and a trigger or function contains 
      two or more inserts/updates in a table that has an autoinc 
      column, then the slave should not go out of sync, even if 
      there are concurrent transactions.
sql/sql_base.cc:
  Added function 'has_write_table_with_auto_increment' to check 
  if one (or more) write tables have auto_increment columns.
  
  Removed function 'has_two_write_locked_tables_with_auto_increment', 
  because the function is included in function 
  'has_write_table_with_auto_increment'.

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

sql/sql_parse.cc:
  DBUG macros are wrapped inside a loop. Allow to break
  the command switch from within a DBUG macro.

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.

mysql-test/r/federated_debug.result:
  Add test case result for Bug#47525
mysql-test/t/federated_debug-master.opt:
  Debug point.
mysql-test/t/federated_debug.test:
  Add test case for Bug#47525
sql/slave.cc:
  Check whether a the thread has a associated session.
sql/sql_parse.cc:
  Add debug code to simulate a reload without thread session.

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

myisam/mi_dbug.c:
  * check_table_is_closed is only used in EXTRA_DEBUG mode but since it is
  iterating over myisam shared data it still needs to be protected by an
  appropriate mutex.
sql/sql_yacc.yy:
  * Since the I_S mechanism is already handling the open and close of 
  mysql.proc there is no need for the method sp_add_to_query_tables.

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.

client/mysqlbinlog.cc:
  Skip the database check for BEGIN/COMMIT/ROLLBACK log events.
mysql-test/r/mysqlbinlog.result:
  Test result for bug#46998
mysql-test/suite/binlog/t/binlog_row_mysqlbinlog_db_filter.test:
  The test case is updated duo to the patch of bug#46998
mysql-test/t/mysqlbinlog.test:
  Added test to verify if the 'BEGIN', 'COMMIT' and 'ROLLBACK' are output
  in regardless of database filtering

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.

client/mysqlbinlog.cc:
  Skip the database check for BEGIN/COMMIT/ROLLBACK log events.
mysql-test/r/mysqlbinlog.result:
  Test result for bug#46998
mysql-test/t/mysqlbinlog.test:
  Added test to verify if the 'BEGIN', 'COMMIT' and 'ROLLBACK' are output
  in regardless of database filtering

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.


.bzrignore:
  WL#4259 - Debug Sync Facility
  Added the symbolic link libmysqld/debug_sync.cc.
CMakeLists.txt:
  WL#4259 - Debug Sync Facility
  Added definition for ENABLED_DEBUG_SYNC.
configure.in:
  WL#4259 - Debug Sync Facility
  Added definition for ENABLED_DEBUG_SYNC.
include/my_sys.h:
  WL#4259 - Debug Sync Facility
  Added definition for the DEBUG_SYNC_C macro.
libmysqld/CMakeLists.txt:
  WL#4259 - Debug Sync Facility
  Added sql/debug_sync.cc.
libmysqld/Makefile.am:
  WL#4259 - Debug Sync Facility
  Added sql/debug_sync.cc.
mysql-test/include/have_debug_sync.inc:
  WL#4259 - Debug Sync Facility
  New include file.
mysql-test/mysql-test-run.pl:
  WL#4259 - Debug Sync Facility
  Added option --debug_sync_timeout.
mysql-test/r/debug_sync.result:
  WL#4259 - Debug Sync Facility
  New test result.
mysql-test/r/have_debug_sync.require:
  WL#4259 - Debug Sync Facility
  New require file.
mysql-test/t/debug_sync.test:
  WL#4259 - Debug Sync Facility
  New test file.
mysys/my_static.c:
  WL#4259 - Debug Sync Facility
  Added definition for debug_sync_C_callback_ptr.
mysys/thr_lock.c:
  WL#4259 - Debug Sync Facility
  Added sync point "wait_for_lock".
sql/CMakeLists.txt:
  WL#4259 - Debug Sync Facility
  Added debug_sync.cc and debug_sync.h.
sql/Makefile.am:
  WL#4259 - Debug Sync Facility
  Added debug_sync.cc and debug_sync.h.
sql/debug_sync.cc:
  WL#4259 - Debug Sync Facility
  New source file.
sql/debug_sync.h:
  WL#4259 - Debug Sync Facility
  New header file.
sql/mysqld.cc:
  WL#4259 - Debug Sync Facility
  Added opt_debug_sync_timeout.
  Added calls to debug_sync_init() and debug_sync_end().
  Fixed a purecov comment (unrelated).
sql/set_var.cc:
  WL#4259 - Debug Sync Facility
  Added server variable "debug_sync".
sql/set_var.h:
  WL#4259 - Debug Sync Facility
  Added declaration for server variable "debug_sync".
sql/share/errmsg.txt:
  WL#4259 - Debug Sync Facility
  Added error messages ER_DEBUG_SYNC_TIMEOUT and ER_DEBUG_SYNC_HIT_LIMIT.
sql/sql_base.cc:
  WL#4259 - Debug Sync Facility
  Added sync points "after_flush_unlock" and "before_lock_tables_takes_lock".
sql/sql_class.cc:
  WL#4259 - Debug Sync Facility
  Added initialization for debug_sync_control to THD::THD.
  Added calls to debug_sync_init_thread() and debug_sync_end_thread().
sql/sql_class.h:
  WL#4259 - Debug Sync Facility
  Added element debug_sync_control to THD.
storage/myisam/myisamchk.c:
  Fixed a typo in an error message string (unrelated).

          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.

sql/sql_yacc.yy:
  * Set lock_option to either TL_READ_NO_INSERT or
    TL_READ for any sub-SELECT following UPDATE.
  * Changed line adjusted for parser identation
    rules; code begins at column 13.

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

mysql-test/lib/mtr_cases.pm:
  Use ':' as the separator on non-Windows platforms.
mysql-test/mysql-test-run.pl:
  Remove unnecessary use of the separator.

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.

mysql-test/r/alter_table.result:
  Add test case result for Bug#45567
mysql-test/t/alter_table.test:
  Add test case for Bug#45567
sql/field.cc:
  Check whether two fields can be considered 'equal' for table
  alteration purposes. Fields are equal if they retain the same
  pack length and if new members are added to the end of the list.
sql/field.h:
  Add comment and remove method.

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.



mysql-test/r/join.result:
  test result
mysql-test/t/join.test:
  test case
sql/item.cc:
  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.