"Trigger fired multiple times leads to gaps in auto_increment sequence".
The bug was that if a trigger fired multiple times inside a top
statement (for example top-statement is a multi-row INSERT,
and trigger is ON INSERT), and that trigger inserted into an auto_increment
column, then gaps could be observed in the auto_increment sequence,
even if there were no other users of the database (no concurrency).
It was wrong usage of THD::auto_inc_intervals_in_cur_stmt_for_binlog.
Note that the fix changes "class handler", I'll tell the Storage Engine API team.

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

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

Removes the regression bug#38751.

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.

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.

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

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.

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.

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.

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

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.