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.

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

          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.

Add --help option.

by Svoj over e-mail.

"load data" statements were written to the binlog as a mix of the original statement
and bits recreated from parse-info. This relied on implementation details and broke
with IGNORE_SPACES and versioned comments.

We now completely resynthesize the query for LOAD DATA for binlog (which among other
things normalizes them somewhat with regard to case, spaces, etc.).
We have already parsed the query properly, so we make use of that rather
than mix-and-match string literals and parsed items.
This should make us safe with regard to versioned comments, even those
spanning multiple tokens. Also no longer affected by IGNORE_SPACES.

mysql-test/r/mysqlbinlog.result:
  LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_killed_simulate.result:
  LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
  LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
  LOAD DATA INFILE normalized
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
  LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
  LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_loaddata.result:
  LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_loaddata_fatal.result:
  LOAD DATA INFILE normalized; offsets adjusted to reflect that
mysql-test/suite/rpl/r/rpl_loaddata_map.result:
  LOAD DATA INFILE normalized
mysql-test/suite/rpl/r/rpl_loaddatalocal.result:
  test for #43746 - trying to break LOAD DATA part of parser
mysql-test/suite/rpl/r/rpl_stm_log.result:
  LOAD DATA INFILE normalized
mysql-test/suite/rpl/t/rpl_loaddatalocal.test:
  try to break the LOAD DATA part of the parser (test for #43746)
mysql-test/t/mysqlbinlog.test:
  LOAD DATA INFILE normalized; adjust offsets to reflect that
sql/log_event.cc:
  clean up Load_log_event::print_query and friends so they don't print
  excess spaces. add support for printing charset names to print_query.
sql/log_event.h:
  We already have three places where we synthesize LOAD DATA queries.
  Better use one of those!
sql/sql_lex.h:
  When binlogging LOAD DATA statements, we make up the statement to
  be logged (from the parse-info, rather than substrings of the
  original query) now. Consequently, we no longer need (string-)
  pointers into the original query.
sql/sql_load.cc:
  Completely rewrote write_execute_load_query_log_event() to synthesize the
  LOAD DATA statement wholesale, rather than piece it together from
  synthesized bits and literal excerpts from the original query. This
  will not only give us a nice, normalized statement (all uppercase,
  no excess spaces, etc.), it will also handle comments, including
  versioned comments right, which is certainly more than we can say
  about the previous incarnation.
sql/sql_yacc.yy:
  We're no longer assembling LOAD DATA statements from bodyparts of the
  original query, so some bookkeeping in the parser can go.

Bug#35996: SELECT + SHOW VIEW should be enough to display
view definition

During SHOW CREATE VIEW there is no reason to 'anonymize'
errors that name objects that a user does not have access
to. Moreover it was inconsistently implemented. For example
base tables being referenced from a view appear to be ok,
but not views. The manual on the other hand is clear: If a
user has the privileges SELECT and SHOW VIEW, the view
definition is available to that user, period. The fix
changes the behavior to support the manual.


mysql-test/r/information_schema_db.result:
  Bug#35996: Changed warnings.
mysql-test/r/view_grant.result:
  Bug#35996: Changed warnings, test result.
mysql-test/t/information_schema_db.test:
  Bug#35996: Changed test case to reflect new behavior.
mysql-test/t/view_grant.test:
  Bug#35996: Test case.
sql/sql_acl.cc:
  Bug#35996: Code no longer necessary, we may as well exempt 
  SHOW CREATE VIEW from this check.
sql/sql_show.cc:
  Bug#35996: The fix: An Internal_error_handler that hides
  most errors raised by access checking as they are not
  relevant to SHOW CREATE VIEW.
sql/table.cc:
  Bug#35996: Restricting this hack to act only when there is 
  no Internal_error_handler.

Bug#46958: Assertion in Diagnostics_area::set_ok_status, 
trigger, merge table
            
The problem with break statements is that they have very
local effects. Hence a break statement within the inner loop
of a nested-loops join caused execution to proceed to the
next table even though a serious error occurred. The problem
was fixed by breaking out the inner loop into its own
method. The change empowers all errors to terminate the
execution.
            
The errors that will now halt multi-DELETE execution
altogether are 
  - triggers returning errors
  - handler errors
  - server being killed


mysql-test/r/delete.result:
  Bug#46958: Test result.
mysql-test/t/delete.test:
  Bug#46958: Test case.
sql/sql_class.h:
  Bug#46958: New method declaration.
sql/sql_delete.cc:
  Bug#46958: New method implementation.

All statements executed by mysql_upgrade are binlogged and then are replicated to slave.
This will result in some errors. The report of this bug has demonstrated some examples.

Master and slave should be upgraded separately. All statements executed by
mysql_upgrade will not be binlogged. 
--write-binlog and --skip-write-binlog options are added into mysql_upgrade. 
These options control whether sql statements are binlogged or not. 

      
In RBR, 'DROP TEMPORARY TABLE IF EXISTS...' statement is binlogged when the table
does not exist.
      
In fact, 'DROP TEMPORARY TABLE ...' statement should never be binlogged in RBR
no matter if the table exists or not. 
This patch addresses this by checking whether we are dropping a
temporary table or not, when building the custom drop statement.