When using Unique Keys with nullable parts in RBR, the slave can
choose the wrong row to update. This happens because a table with
an unique key containing nullable parts cannot strictly guarantee 
uniqueness. As stated in the manual, for all engines, a UNIQUE 
index allows multiple NULL values for columns that can contain 
NULL.

We fix this at the slave by extending the checks before assuming
that the row found through an unique index is is the correct
one. This means that when a record (R) is fetched from the storage
engine and a key that is not primary (K) is used, the server does 
the following: 

 - If K is unique and has no nullable parts, it returns R;
 - Otherwise, if any field in the before image that is part of K
   is null do an index scan;
 - If there is no NULL field in the BI part of K, then return R.

A side change: renamed the existing test case file and added a
test case covering the changes in this patch.

Problem: The test case mysqldump reads a file that must
be world-readable. The test did not force the file to be
world-readable, so if the tree was branched with a umask
of 0077, the test would fail.
Fix: chmod the file.


mysql-test/t/mysqldump.test:
  Added chmod so that the file is guaranteed to be world-readable.

Server crashes on 64bit linux with 'double free or corruption'
message, on 32bit mysql-test-run silently fails on bootstrap
stage. The problem is that FreeState() is called twice
for init_settings struct in _db_end_ function.
The fix is to remove superfluous FreeState() call.
Additional fix:
fixed discrepancy of result file when
debug & valgrind options are enabled
for MTR.

dbug/dbug.c:
  The problem is that FreeState() is called twice
  for init_settings struct in _db_end_ function.
  The fix is to remove superfluous FreeState() call.
mysql-test/r/variables_debug.result:
  fixed discrepancy of result file when
  debug & valgrind options are enabled
  for MTR.
mysql-test/t/variables_debug.test:
  fixed discrepancy of result file when
  debug & valgrind options are enabled
  for MTR.
sql/set_var.cc:
  fixed discrepancy of result file when
  debug & valgrind options are enabled
  for MTR.

Bug #50087 Interval arithmetic for Event_queue_element is not portable.

Subtraction of two unsigned months yielded a (very large) positive value.
Conversion of this to a signed value was not necessarily well defined.
              
Solution: do the subtraction on signed values.



mysql-test/r/events_scheduling.result:
  Add test case.
mysql-test/t/events_scheduling.test:
  Add test case.
sql/event_data_objects.cc:
  Convert month to signed before doing the subtraction.

Analysis showed that in case of accessing I_S table
ROUTINES we perform unnecessary allocations
with get_field() function for every processed row that
in their turn causes significant memory growth.
the fix is to avoid use of get_field().


sql/sql_show.cc:
  Functions store_schema_proc() are changed
  to avoid use of get_field() function.

mode
      
Post-push fix after backporting the patch to 5.1-bugteam:

  1 - changed the name of some variables to be equivalent to pe.
  2 - fixed that patch to mark a statement as unsafe when both a
  self-logging eng. and regular eng. are accessed and one of them
  is updated.

Post-fix: Updated a test case after the patch for BUG#50410,
because the patch makes ndb to run in the row format and as
such unsafe warning messages are not printed out.

            ha_myisam::index_first(uchar*)") at assert.c:81

Single-table DELETE crash/assertion similar to single-table
UPDATE bug 14272.

Same resolution as for the bug 14272:
Don't run index scan when we should use quick select.
This could cause failures because there are table handlers (like federated)
that support quick select scanning but do not support index scanning.


mysql-test/r/delete.result:
  Test case for bug #53450.
mysql-test/t/delete.test:
  Test case for bug #53450.
sql/sql_delete.cc:
  Bug #53450: Crash / assertion "virtual int
              ha_myisam::index_first(uchar*)") at assert.c:81
  
  The mysql_delete function has been modified to not to use
  init_read_record_idx instead of init_read_record for the
  quick select.

MTR sporadically reported that rpl_do_grant does not
clean up after itself.

We fix this by backporting BUG 50984 fix. This deploys
missing synchronization between master and slave.

Additionally, it also fixes the check_testcase for
rpl_tmp_table_and_DDL.

      NULL from outer join query
      
      Problem: optimising MIN/MAX() queries without GROUP BY clause
      by replacing the aggregate expression with a constant, we may set it
      to NULL disregarding the fact that there may be outer joins involved.
      
      Fix: don't replace MIN/MAX() with NULL if there're outer joins.
      
      Note: the fix itself is just
      - if (!count)
      + if (!count && !outer_tables)
          set to NULL
      
      The rest of the patch eliminates repeated code to improve speed
      and for easy maintenance of the code.


mysql-test/r/group_by.result:
          Fix for bug#52051: Aggregate functions incorrectly returns
          NULL from outer join query
            - test result.
mysql-test/t/group_by.test:
          Fix for bug#52051: Aggregate functions incorrectly returns
          NULL from outer join query
            - test case.
sql/opt_sum.cc:
          Fix for bug#52051: Aggregate functions incorrectly returns
          NULL from outer join query
            - optimising MIN/MAX() queries without GROUP BY clause by
          replacing them with a constant, take into account that
          there're may be outer joins involved.
            - repeated code for MIN/MAX optimization in the opt_sum_query()
          eliminated by introducing new functions that read MIN/MAX values
          using index and combining MIN/MAX cases to one.

update statements
      
Only SELECT statements report any examined rows in the slow
log. Slow UPDATE, DELETE and INSERT statements report 0 rows
examined, unless the statement has a condition including a
SELECT substatement.
      
This patch adds counting of examined rows for the UPDATE and
DELETE statements. An INSERT ... VALUES statement will still 
not report any rows as examined.



sql/sql_class.h:
  Added more docs for THD::examined_row_count.
sql/sql_delete.cc:
  Add incrementing thd->examined_row_count.
sql/sql_update.cc:
  Add incrementing thd->examined_row_count.

Problem: The rpl_ndb did not set binlog_format explicitly. Since
the default is binlog_format=statement, it means that the suite
ran with that. ndb does not support binlog_format=statement,
and many tests were skipped because they sourced
include/have_binlog_format_row_or_mixed.inc
Fix: set binlog_format=row explicitly in the configuration file
for the rpl_ndb suite.


Makefile.am:
  Removed duplicate run of rpl_ndb suite with binlog_format=row.
  Now that rpl_ndb is run with binlog_format=row by default, this
  run that explicitly changes to binlog_format=row is not needed,
  because it is covered by the following run.
mysql-test/suite/rpl_ndb/my.cnf:
  cluster only supports binlog_format=row.
mysql-test/suite/rpl_ndb/r/rpl_ndb_stm_innodb.result:
  updated result file
mysql-test/suite/rpl_ndb/t/rpl_ndb_stm_innodb.test:
  This test is supposed to use binlog_format=STATEMENT on
  master. It uses innodb on master, so statement format is
  supported.

      
MySQL handles the join syntax "JOIN ... USING( field1,
... )" and natural joins by building the same parse tree as
a corresponding join with an "ON t1.field1 = t2.field1 ..."
expression would produce. This parse tree was not cleaned up
properly in the following scenario. If a thread tries to
lock some tables and finds that the tables were dropped and
re-created while waiting for the lock, it cleans up column
references in the statement by means a per-statement free
list. But if the statement was part of a stored procedure,
column references on the stored procedure's free list
weren't cleaned up and thus contained pointers to freed
objects.
      
Fixed by adding a call to clean up the current prepared
statement's free list.

This is a backport from MySQL 5.1

remember range endpoints

The Loose Index Scan optimization keeps track of a sequence
of intervals. For the current interval it maintains the
current interval's endpoints. But the maximum endpoint was
not stored in the SQL layer; rather, it relied on the
storage engine to retain this value in-between reads. By
coincidence this holds for MyISAM and InnoDB. Not for the
partitioning engine, however.

Fixed by making the key values iterator 
(QUICK_RANGE_SELECT) keep track of the current maximum endpoint.
This is also more efficient as we save a call through the
handler API in case of open-ended intervals.

The code to calculate endpoints was extracted into 
separate methods in QUICK_RANGE_SELECT, and it was possible to
get rid of some code duplication as part of fix.

that generated multiple result sets (such as a stored procedure or a
multi-statement command) would leave the connection unusable. (Bug #42373)

A side-effect of this bug fix is to make MYSQL_INIT_COMMAND settings ignored
when connecting from within the server, but none of the existing mechanisms
for connecting from within the server use or need to set the initial command.

Backport of the patch for 5.1-bugteam.

MYSQL_BIN_LOG m_table_map_version member and it's associated 
functions were not used in the logic of binlogging and replication,
this patch removed all related code.

sql/log.cc:
  removed unused m_table_map_version variable and functions
sql/log.h:
  removed unused m_table_map_version variable and functions
sql/log_event.h:
  Removed unused LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F flag
sql/sql_class.cc:
  Removed unused LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F flag
sql/sql_load.cc:
  Removed unused LOG_EVENT_UPDATE_TABLE_MAP_VERSION_F flag
sql/table.cc:
  removed unused table_map_version variable
sql/table.h:
  removed unused table_map_version variable

When using a non-transactional table (t1) on the master 
and with autocommit disabled, no COMMIT is recorded 
in the binary log ending the statement. Therefore, if 
the slave has t1 in a transactional engine, then it will 
be as if a transaction is started but never ends. This is
actually BUG#29288 all over again.

We fix this by cherrypicking the cset for BUG#29288 which
was pushed to a later mysql version. The revision picked
was: mats@sun.com-20090923094343-bnheplq8n95opjay .

Additionally, a test case for covering the scenario depicted
in the bug report is included in this cset.

The fix actually reverts the change introduced
by the patch for bug 51494.
The fact is that patches for bugs 52177&48419
fix bugs 51194&50575 as well.



mysql-test/r/innodb_mysql.result:
  test case
mysql-test/t/innodb_mysql.test:
  test case
sql/sql_select.cc:
  reverted wrong fix for bug 51494

            truncates text/blob to 766 chars

mysqldump and SELECT ... INTO OUTFILE truncated long BLOB/TEXT
values to size of 766 bytes (MAX_FIELD_WIDTH or 255 * 3 + 1).

The select_export::send_data method has been modified to
reallocate a conversion buffer for long field data.


mysql-test/r/mysqldump.result:
  Test case for bug #53088.
mysql-test/r/outfile_loaddata.result:
  Test case for bug #53088.
mysql-test/t/mysqldump.test:
  Test case for bug #53088.
mysql-test/t/outfile_loaddata.test:
  Test case for bug #53088.
sql/sql_class.cc:
  Bug #53088: mysqldump with -T & --default-character-set set
              truncates text/blob to 766 chars
  
  The select_export::send_data method has been modified to
  reallocate a conversion buffer for long field data.

greedy_search optimizer_search_depth=0

The algorithm inside restore_prev_nj_state failed to
properly update the counters within the NESTED_JOIN
tree. The counter was decremented each time a table in the
node was removed from the QEP, the correct thing to do being
only to decrement it when the last table in the child node
was removed from the plan. This lead to node counters
getting negative values and the plan thus appeared
impossible. An assertion caught this.

Fixed by not recursing up the tree unless the last table in
the join nest node is removed from the plan

Bug#53417 my_getwd() makes assumptions on the buffer sizes which not always hold true
      
The mysys library contains many functions for rewriting file paths. Most of these
functions makes implicit assumptions on the buffer sizes they write to. If a path is put
in my_realpath() it will propagate to my_getwd() which assumes that the buffer holding
the path name is greater than 2. This is not true in cases.
      
In the special case where a VARBIN_ITEM is passed as argument to the LOAD_FILE function
this can lead to a crash.
      
This patch fixes the issue by introduce more safe guards agaist buffer overruns.

The test was used to fail because of 
 UPDATE t3,t4 SET t3.a=t4.a + bug27417(1);
did not prescribe the order of two row operations implied by the update.

Fixed with forcing the order with adding a where condition w/o
affecting the former bug fixes logics.

mysql-test/extra/binlog_tests/mix_innodb_myisam_side_effects.test:
  implemented the bug page suggestion to make a test deterministic.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
  results are updated and (!) corrected.
mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result:
  results are updated

This is the 5.1 merge and extension of the fix.
The server was happily accepting paths in table name in all places a table
name is accepted (e.g. a SELECT). This allowed all users that have some 
privilege over some database to read all tables in all databases in all
mysql server instances that the server file system has access to.
Fixed by :
1. making sure no path elements are allowed in quoted table name when
constructing the path (note that the path symbols are still valid in table names
when they're properly escaped by the server).
2. checking the #mysql50# prefixed names the same way they're checked for
path elements in mysql-5.0.

      
When issuing a 'SET GLOBAL SQL_SLAVE_SKIP_COUNTER' statement, the previous
position along with the new position is dumped into the error log. Namely,
the following information is printed out: skip_counter, group_relay_log_name
and group_relay_log_pos.

      
When issuing a 'CHANGE MASTER TO' statement, key elements of the previous
state, namely the host, port, the master_log_file and the master_log_pos
are dumped into the error log.

Iterative patch improvement. Previously committed patch
caused wrong result on Windows. The previous patch also
broke secure_file_priv for symlinks since not all file
paths which must be compared against this variable are
normalized using the same norm.

The server variable opt_secure_file_priv wasn't
normalized properly and caused the operations
LOAD DATA INFILE .. INTO TABLE ..
and
SELECT load_file(..)
to do different interpretations of the 
--secure-file-priv option.
     
The patch moves code to the server initialization
routines so that the path always is normalized
once and only once.
      
It was also intended that setting the option
to an empty string should be equal to 
lifting all previously set restrictions. This
is also fixed by this patch.


mysql-test/r/loaddata.result:
  * Removed test code which will currently break the much used --mem feature of mtr.
mysql-test/t/loaddata.test:
  * Removed test code which will currently break the much used --mem feature of mtr.
sql/item_strfunc.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/mysql_priv.h:
  * Added signature for is_secure_file_path()
sql/mysqld.cc:
  * New function for checking if a path compatible with the secure path restriction.
  * Added initialization of the opt_secure_file_priv variable.
sql/sql_class.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.
sql/sql_load.cc:
  * Replaced string comparing code on opt_secure_file_priv with an interface which guarantees that both file paths are normalized using the same norm on all platforms.

The server was not checking the supplied to COM_FIELD_LIST table name
for validity and compliance to acceptable table names standards.
Fixed by checking the table name for compliance similar to how it's 
normally checked by the parser and returning an error message if 
it's not compliant.