The fix inserts newline and comma characters as appropriate
into the constraint reporting code to match the formatting
required by SHOW CREATE TABLE. Additionally, a erroneously
duplicated copy of check_if_incompatible_data() was removed
from db2i_constraints.cc since the correct version is already
in ha_ibmdb2i.cc.

storage/ibmdb2i/db2i_constraints.cc:
  Bug#49521 SHOW CREATE TABLE on IBMDB2I tables has incorrect fk constraint format
  
  - Insert newline and comma characters into the constraint reporting
    code to match the formatting required by SHOW CREATE TABLE.
  
  - Remove an erroneous copy of check_if_incompatible_data() from
    db2i_constraints.cc.

This fix changes the character set used within the
IBMDB2I handler to hash table names to information
about open tables. Previously, tables with names
that differed only in letter case would hash to the
same data structure. This caused incorrect behavior
or errors when two such tables were in use simultaneously.

mysql-test/suite/ibmdb2i/r/ibmdb2i_bug_49329.result:
  Bug#49329 example (and other) engines use wrong collation for open tables hash
  
  Result file for the test case.
mysql-test/suite/ibmdb2i/t/ibmdb2i_bug_49329.test:
  Bug#49329 example (and other) engines use wrong collation for open tables hash
  
  Test case for the bug fix.
storage/ibmdb2i/ha_ibmdb2i.cc:
  Bug#49329 example (and other) engines use wrong collation for open tables hash
  
  change the character set used within the IBMDB2I
  handler to hash table names to information about
  open tables.

      
The help text for --init-slave=name:
"Command(s) that are executed when a slave connects to this master".
This text indicate that the --init-slave option is set on a  master 
server, and the master server passes the option's argument to slave 
which connects to it. This is wrong. Actually the --init-slave option 
just can be set on a slave server, and then the slave server executes 
the argument each time the SQL thread starts.

Correct the help text for --init-slave option as following:
"Command(s) that are executed by a slave server each time the SQL thread starts."


sql/mysqld.cc:
  Correct the help text for --init-slave option.

The help text for --init-slave=name:
"Command(s) that are executed when a slave connects to this master".
This text indicate that the --init-slave option is set on a  master 
server, and the master server passes the option's argument to slave 
which connects to it. This is wrong. Actually the --init-slave option 
just can be set on a slave server, and then the slave server executes 
the argument each time the SQL thread starts.

Correct the help text for --init-slave option as following:
"Command(s) that are executed by a slave server each time the SQL thread starts."


sql/mysqld.cc:
  Correct the help text for --init-slave option.

SPATIAL and FULLTEXT indexes don't support algorithm
selection. 
Disabled by creating a special grammar rule for these
in the parser.
Added some encasulation of duplicate parser code.

A few problems were found in the fix for bug 43668:
1) Comparison of the YEAR column with NULL always returned TRUE;
2) Comparison of the YEAR column with constants always returned
   unpredictable result;
3) Unnecessary conversion warnings when comparing a non-integer
   constant with a NULL value in the YEAR column;

The problems described above have been resolved with an
exception: zero (i.e. invalid) YEAR column value comparison
with 00 or 2000 still fail (it is not a regression and it was
not a regression), so MIN/MAX on YEAR column containing zero
value still fail.


mysql-test/r/type_year.result:
  Test case for bug #49480.
mysql-test/t/type_year.test:
  Test case for bug #49480.
sql/item_cmpfunc.cc:
  - The get_year_value() function has been modified to make its
    return value compatible with the get_datetime_value() return
    value (i.e. to convert numeric values into the YYYY0000000000
    (YYYY-00-00 00:00:00) form.
  
  - The Arg_comparator::set_cmp_func method has been modified to
    use the get_year_value function if get_datetime_value() is not
    applicable.
    From now only 2 cases have a special processing there:
    * both comparing items have MYSQL_TYPE_YEAR field type
            or
    * one item have is MYSQL_TYPE_YEAR and other one is
      is_datetime()-compliant.
  
  - New helper function try_year_cmp_func() has been
    added for the better code readability to call from
    Arg_comparator::set_cmp_func().
  
  - The Arg_comparator::compare_year method has been removed
    since get_year_value() is compatible with the old
    Arg_comparator::compare_datetime method that doesn't have
    problems #1-#3 (see whole patch entry commentary).
sql/item_cmpfunc.h:
  - New helper function try_year_cmp_func() has been
    added for the better code readability to call from
    Arg_comparator::set_cmp_func().
  
  - Unnecessary Arg_comparator::year_as_datetime and
    Arg_comparator::compare_year() declarations have been
    removed.

mysql-test/include/kill_query.inc:
  Error 1034 can be generated when change MyISAM table indexes was interrupted
mysql-test/r/rpl_killed_ddl.result:
  table t4 may not exists because the ALTER above was interrupted
mysql-test/t/rpl_killed_ddl.test:
  table t4 may not exists because the ALTER above was interrupted

      
This fix has been proposed by Sergey Petrunya and has been contributed
under SCA by sca@askmonty.org.
      
The cause for this valgrind error is that in the function
add_cond_and_fix() in sql_select.cc an Item_cond_and object is
created. This is marked as fixed but does not have a correct
table_map() attribute. Later, in make_join_select(), if
engine_condition_pushdown is in use, this table map is used and
results in the valgrind error.
      
The fix is to add a call to update_used_tables() in add_cond_and_fix()
so that the table map is updated correctly.
      
This patch is tested by multiple existing tests (e.g. the tests
innodb_mysql, innodb, fulltext, compress all produces this valgrind
warning/error without this fix).


sql/sql_select.cc:
  In add_cond_and_fix() add a call to update_used_tables() to ensure
  the table map is updated.

There are three issues that caused rpl_killed_ddl fails sporadically
in pb2:

 1) thd->clear_error() was not called before create Query event
if operation is executed successfully.
 2) DATABASE d2 might do exist because the statement to CREATE or
ALTER it was killed
 3) because of bug 43353, kill the query that do DROP FUNCTION or
    DROP PROCEDURE can result in SP not found

This patch fixed all above issues by:
 1) Called thd->clear_error() if the operation succeeded.
 2) Add IF EXISTS to the DROP DATABASE d2 statement
 3) Temporarily disabled testing DROP FUNCTION/PROCEDURE IF EXISTS.

mysql-test/t/rpl_killed_ddl.test:
  DATABASE d2 might not exists, add IF EXITS to the DROP statement
sql/sql_db.cc:
  Called thd->clear_error() if the operation succeeded

Disabled execution in valgrind to avoid false positive memory
leaks due to fault-injection tests (i.e. call to abort()).

Part 2 : 
There was a special optimization on the ref access method for 
ORDER BY ... DESC that was set without actually looking on the type of the 
selected index for ORDER BY.
Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared
to the ASC that has been fixed with the previous fix).

Removed rpl_cross_version from experimental list.

{PROCEDURE|FUNCTION} FROM ...'

The master would hit an assertion when binary log was
active. This was due to the fact that the thread's diagnostics
area was being cleared before writing to the binlog,
independently of mysql_routine_grant returning an error or
not. When mysql_routine_grant was to return an error, the return
value and the diagnostics area contents would
mismatch. Consequently, neither my_ok would be called nor an
error would be signaled in the diagnostics area, eventually
triggering the assertion in net_end_statement.

We fix this by not clearing the diagnostics area at binlogging
time. 

solaris after a crash
      
This patch adds a Solaris-specific version of
print_stacktrace() which uses printstack(2), available on all
Solaris versions since Solaris 9. (While Solaris 11 adds
support for the glibc functions backtrace_*() as of
PSARC/2007/162, printstack() is used for consistency over all
Solaris versions.)

The symbol names are mangled, so use of c++filt may be
required as described in the MySQL documentation.


sql/stacktrace.c:
  Added Solaris-specific print_stacktrace().

field='const1' AND field='const2' in some cases

Building multiple equality predicates containing
a constant which is compared as a datetime (with a field)
we should take this fact into account and compare the 
constant with another possible constatns as datetimes 
as well.

E.g. for the
SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
we should compare '2001-01-01' with '2001-01-01 00:00:00' as
datetimes but not as strings.


mysql-test/r/select.result:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - test result.
mysql-test/t/select.test:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - test case.
sql/item_cmpfunc.cc:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - adding a constant to Item_equal compare it as
  a datetime value with stored one if there's a 
  date[time] field in a equality predicate.
sql/item_cmpfunc.h:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - adding a constant to Item_equal compare it as
  a datetime value with stored one if there's a 
  date[time] field in a equality predicate.
sql/sql_select.cc:
  Fix for bug#49199: Optimizer handles incorrectly: 
  field='const1' AND field='const2' in some cases
    - adding a constant to Item_equal compare it as
  a datetime value with stored one if there's a 
  date[time] field in a equality predicate.

The problem was that the multiple evaluations of a ENCODE or
DECODE function within a single statement caused the random
generator to be reinitialized at each evaluation, even though
the parameters were constants.

The solution is to initialize the random generator only once
if the password (seed) parameter is constant.

This patch borrows code and ideas from Georgi Kodinov's patch.

mysql-test/r/func_str.result:
  Add test case result.
mysql-test/r/ps.result:
  Add test case result.
mysql-test/t/func_str.test:
  Add test case for Bug#49141
mysql-test/t/ps.test:
  Add test case for Bug#49141
sql/item_strfunc.cc:
  Move seed generation code to a separate method.
  Seed only once if the password (seed) argument
  is constant.
  Remove duplicated code and use a transform method
  to apply encoding or decoding.
sql/item_strfunc.h:
  Add parameter to signal whether the PRNG is already seeded.
  Introduce transform method.
  Combine val_str methods.
sql/sql_crypt.cc:
  Remove method.
sql/sql_crypt.h:
  Seed is supplied as two long integers.

Post-merge fix: Redirect stderr to a file as to avoid buffering
problems due to redirecting stderr to stdout.

mysql-test/r/mysql_upgrade.result:
  Update test case result.
mysql-test/t/mysql_upgrade.test:
  Redirect stderr to a file, cat and remove.

This patch fixes three bugs as follows. First, aborting the server while purging
binary logs might generate orphan files due to how the purge operation was
implemented:

          (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)

      1 - register the files to be removed in a temporary buffer.
      2 - update the log-bin.index.
      3 - flush the log-bin.index.
      4 - erase the files whose names where register in the temporary buffer
      in step 1.

Thus a failure while  executing step 4 would generate an orphan file. Second,
a similar issue might happen while creating a new binary as follows:

          (create routine - sql/log.cc - MYSQL_BIN_LOG::open)

      1 - open the new log-bin.
      2 - update the log-bin.index.

Thus a failure while executing step 1 would generate an orphan file.

To fix these issues, we record the files to be purged or created before really
removing or adding them. So if a failure happens such records can be used to
automatically remove dangling files. The new steps might be outlined as follows:

          (purge routine - sql/log.cc - MYSQL_BIN_LOG::purge_logs)

      1 - register the files to be removed in the log-bin.~rec~ placed in
      the data directory.
      2 - update the log-bin.index.
      3 - flush the log-bin.index.
      4 - delete the log-bin.~rec~.

          (create routine - sql/log.cc - MYSQL_BIN_LOG::open)

      1 - register the file to be created in the log-bin.~rec~
      placed in the data directory.
      2 - open the new log-bin.
      3 - update the log-bin.index.
      4 - delete the log-bin.~rec~.

          (recovery routine - sql/log.cc - MYSQL_BIN_LOG::open_index_file)

      1 - open the log-bin.index.
      2 - open the log-bin.~rec~.
      3 - for each file in log-bin.~rec~.
        3.1 Check if the file is in the log-bin.index and if so ignore it.
        3.2 Otherwise, delete it.

The third issue can be described as follows. The purge operation was allowing
to remove a file in use thus leading to the loss of data and possible
inconsistencies between the master and slave. Roughly, the routine was only
taking into account the dump threads and so if a slave was not connect the
file might be delete even though it was in use.

After-push minor code cleanup for WL 2360: unnecessary external
reference to LOCK_thread_count has been removed from ha_innodb.cc.

"mysql_upgrade (ver 5.1) add 3 fields to mysql.proc table but does
not set values".
            
mysql_upgrade (ver 5.1) adds 3 fields (character_set_client, 
collation_connection and db_collation) to the mysql.proc table, but 
does not set any values. When we run stored procedures, which were 
created with mysql 5.0, a warning is logged into the error log.
            
The solution to this is for mysql_upgrade to set default best guess
values for these fields. A warning is also written during upgrade, to
make the user aware that default values are set.

client/mysql_upgrade.c:
  Result lines which start with "WARNING" are passed through to the output. 
  This way we have a way of triggering WARNING-messages during upgrade 
  directly from the .sql-script.
mysql-test/r/mysql_upgrade.result:
  Expected result of the test.
mysql-test/t/mysql_upgrade.test:
  Added a test-case for the bug.
scripts/mysql_system_tables_fix.sql:
  The new fields are populated, and warnings are written.

Test case cleanup.

mysql-test/r/ps.result:
  Test case cleanup for bug#48508.
mysql-test/t/ps.test:
  Test case cleanup for bug#48508.