there were no blackhole installed. This patch
adds a check for that.

mysql-test/suite/rpl/t/rpl_blackhole.test:
  Adding include of have_blackhole.

The problem was caused by a wrong merge. Fixed by enabling the correct ndb variables
initialization.

mysql-test/suite/ndb/t/disabled.def:
  Bug #38370: remove disabled test case
sql/mysqld.cc:
  Bug #38370: corrected a wrong merge to have all the NDB variables intiialized
  correctly

Incremental patch to add comments to test cases.

      
The optimizer pulls up aggregate functions which should be aggregated in
an outer select. At some point it may substitute such a function for a field
in the temporary table. The setup_copy_fields function doesn't take this
into account and may overrun the copy_field buffer.
      
Fixed by filtering out the fields referenced through the specialized
reference for aggregates (Item_aggregate_ref).
Added an assertion to make sure bugs that cause similar discrepancy 
don't go undetected.

mysql-test/r/func_group.result:
  Bug #37348: test case
mysql-test/t/func_group.test:
  Bug #37348: test case
sql/item.cc:
  Bug #37348: Added a way to distinguish Item_aggregate_ref from the other types of refs
sql/item.h:
  Bug #37348: Added a way to distinguish Item_aggregate_ref from the other types of refs
sql/sql_select.cc:
  Bug #37348: 
   - Don't consider copying field references
      seen through Item_aggregate_ref
   - check for discrepancies between the number of expected 
     fields that need copying and the actual fields copied.

The Blackhole engine did not support row-based replication
since the delete_row(), update_row(), and the index and range
searching functions were not implemented.

This patch adds row-based replication support for the
Blackhole engine by implementing the two functions mentioned
above, and making the engine pretend that it has found the
correct row to delete or update when executed from the slave
SQL thread by implementing index and range searching functions.

It is necessary to only pretend this for the SQL thread, since
a SELECT executed on the Blackhole engine will otherwise never
return EOF, causing a livelock.


mysql-test/extra/binlog_tests/blackhole.test:
  Blackhole now handles row-based replication.
mysql-test/extra/rpl_tests/rpl_blackhole.test:
  Test helper file for testing that blackhole actually
  writes something to the binary log on the slave.
mysql-test/suite/binlog/t/binlog_multi_engine.test:
  Replication now handles row-based replcation.
mysql-test/suite/rpl/t/rpl_blackhole.test:
  Test that Blackhole works with primary key, index, or none.
sql/log_event.cc:
  Correcting code to only touch filler bits and leave
  all other bits alone. It is necessary since there is
  no guarantee that the engine will be able to fill in
  the bits correctly (e.g., the blackhole engine).
storage/blackhole/ha_blackhole.cc:
  Adding definitions for update_row() and delete_row() to return OK
  when executed from the slave SQL thread with thd->query == NULL
  (indicating that row-based replication events are being processed).
  
  Changing rnd_next(), index_read(), index_read_idx(), and
  index_read_last() to return OK when executed from the slave SQL
  thread (faking that the row has been found so that processing
  proceeds to update/delete the row).
storage/blackhole/ha_blackhole.h:
  Enabling row capabilities for engine.
  Defining write_row(), update_row(), and delete_row().
  Making write_row() private (as it should be).

backporting a part of the bug patch to 5.1.29 tree which uses an older version of mtr.

mysql-test/lib/mtr_report.pl:
  refining a suppression rule.

Bug#37536: Thread scheduling causes performance degradation at low thread count

Deprecated --skip-thread-priority startup option as newer versions of
the server won't change the thread priorities by default.

Giving threads different priorities might yield marginal improvements
in some platforms (where it actually works) but on the other hand it
might cause significant degradation depending on the thread count and
number of processors. Meddling with the thread priorities is a not a
safe bet as it is very dependent on the behavior of the cpu scheduler
and system where MySQL is being run.

From MySQL 6.0 and up the default behavior is that of not modifying
the threads priorities.

sql/mysqld.cc:
  Deprecate --skip-thread-priority

sql/ha_partition.cc:
  pre push fix for bug#38804
  Found a missing 'if' for releasing the mutex

from stored procedure. 

Problem: we replace all references to local variables in stored procedures     
with NAME_CONST(name, value) logging to the binary log. However, if the
value's collation differs we might get an 'illegal mix of collation'           
error as we don't pass the collation to the function.

Fix: pass the value's collation to NAME_CONST().

Note: actually we should pass to NAME_CONST() the value's derivation as well.
It's impossible without the parser modifying. Now we always set the 
derivation to DERIVATION_IMPLICIT, the same as local variables have.


mysql-test/r/binlog.result:
  Fix for bug#39182: Binary log producing incompatible character set query
  from stored procedure.
    - test result.
mysql-test/r/ctype_cp932_binlog.result:
  Fix for bug#39182: Binary log producing incompatible character set query
  from stored procedure.
    - results adjusted.
mysql-test/r/rpl_sp.result:
  Fix for bug#39182: Binary log producing incompatible character set query
  from stored procedure.
    - results adjusted.
mysql-test/t/binlog.test:
  Fix for bug#39182: Binary log producing incompatible character set query
  from stored procedure.
    - test case.
sql/item.cc:
  Fix for bug#39182: Binary log producing incompatible character set query
  from stored procedure.
    - allow NAME_CONST() to get _charset'foo' COLLATE 'bar' strings
  (see Item_func_set_collation).
sql/sp_head.cc:
  Fix for bug#39182: Binary log producing incompatible character set query
  from stored procedure. 
    - pass the value's collation to NAME_CONST().

Repush of change to fix tests on Pushbuild.

Link with mtmalloc on Solaris as it is done in our release builds.
Replace deprecated flag with the newer option as already done in
other scripts.

BUILD/compile-solaris-amd64-forte:
  Link to mtmalloc and replace deprecated flag.
BUILD/compile-solaris-amd64-forte-debug:
  Replace deprecated flag.
BUILD/compile-solaris-sparc:
  Link to mtmalloc.
BUILD/compile-solaris-sparc-forte:
  Link to mtmalloc

Post-merge bug fix: lock_type is a enumeration type and not a bit mask.

sql/sql_cache.cc:
  Check for lock type explicitly. Also err on the safe side and
  invalidate the query cache for any write lock.

Server created "arc" directories inside database directories and
maintained there useless copies of .frm files.

Creation and renaming procedures of those copies as well as
creation of "arc" directories has been discontinued.
Removal procedure has been kept untouched to be able to
cleanup existent database directories by the DROP DATABASE
query. Also view renaming procedure has been updated to remove
these directories.


sql/parse_file.cc:
  Fixed bug #17823: 'arc' directories inside database directories.
  View/table creation and renaming procedures maintained
  backup copies of .frm files. Those copies are unused yet,
  so this feature was incomplete and unnecessary.
  
  1. Unwanted code has been hidden by FRM_ARCHIVE ifdefs
  (the FRM_ARCHIVE macro is not defined).
  
  2. Renaming procedure has been modified to remove obsolete
  "arc" directories.
sql/parse_file.h:
  Fixed bug #17823: 'arc' directories inside database directories.
  The "thd" parameter has been added to the rename_in_schema_file()
  function.
sql/sql_db.cc:
  Fixed bug #17823: 'arc' directories inside database directories.
  Scope of the mysql_rm_arc_files() function has been changed to
  global for use from the parse_file.cc file.
sql/sql_view.cc:
  Fixed bug #17823: 'arc' directories inside database directories.
  Added the "thd" argument to rename_in_schema_file() calls.

     JOIN for the subselect wasn't cleaned if we came upon an error
     during sub_select() execution. That leads to the assertion failure
     in close_thread_tables()

     part of the 6.0 code backported

per-file comments:
  mysql-test/r/sp-error.result
Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
    test result

  mysql-test/t/sp-error.test
Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
    test case

  sql/sp_head.cc
Bug#37949 Crash if argument to SP is a subquery that returns more than one row 
    lex->unit.cleanup() call added if not substatement

The problem is that when statement-based replication was enabled,
statements such as INSERT INTO .. SELECT FROM .. and CREATE TABLE
.. SELECT FROM need to grab a read lock on the source table that
does not permit concurrent inserts, which would in turn be denied
if the source table is a log table because log tables can't be
locked exclusively.

The solution is to not take such a lock when the source table is
a log table as it is unsafe to replicate log tables under statement
based replication. Furthermore, the read lock that does not permits
concurrent inserts is now only taken if statement-based replication
is enabled and if the source table is not a log table.

include/thr_lock.h:
  Introduce yet another lock type that my get upgraded depending
  on the binary log format. This is not a optimal solution but
  can be easily improved later.
mysql-test/r/log_tables.result:
  Add test case result for Bug#34306
mysql-test/suite/binlog/r/binlog_stm_row.result:
  Add test case result for Bug#34306
mysql-test/suite/binlog/t/binlog_stm_row.test:
  Add test case for Bug#34306
mysql-test/t/log_tables.test:
  Add test case for Bug#34306
sql/lock.cc:
  Assert that TL_READ_DEFAULT is not a real lock type.
sql/mysql_priv.h:
  Export new function.
sql/mysqld.cc:
  Remove using_update_log.
sql/sql_base.cc:
  Introduce function that returns the appropriate read lock type
  depending on how the statement is going to be replicated. It will
  only take a TL_READ_NO_INSERT log if the binary is enabled and the
  binary log format is statement-based and the table is not a log table.
sql/sql_parse.cc:
  Remove using_update_log.
sql/sql_update.cc:
  Use new function to choose read lock type.
sql/sql_yacc.yy:
  The lock type is now decided at open_tables time. This old behavior was
  actually misleading as the binary log format can be dynamically switched
  and this would not change for statements that have already been parsed
  when the binary log format is changed (ie: prepared statements).