Queries optimized with GROUP_MIN_MAX didn't cleanup KEYREAD
optimization properly. As a result subsequent queries may
return incomplete rows (fields are initialized to default
values).

logging is disabled

Post-push fix: disabling test when running mysqld in 
               embedded mode.

Grouping by a subquery in a query with a distinct aggregate
function lead to a wrong result (wrong and unordered
grouping values).

There are two related problems:

1) The query like this:

   SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
   FROM t1 GROUP BY aa

returned wrong result, because the outer reference "t1.a"
in the subquery was substituted with the Item_ref item.

The Item_ref item obtains data from the result_field object
that refreshes once after the end of each group. This data
is not applicable to filesort since filesort() doesn't care
about groups (and doesn't update result_field objects with
copy_fields() and so on). Also that data is not applicable
to group separation algorithm: end_send_group() checks every
record with test_if_group_changed() that evaluates Item_ref
items, but it refreshes those Item_ref-s only after the end
of group, that is a vicious circle and the grouped column
values in the output are shifted.

Fix: if
       a) we grouping by a subquery and
       b) that subquery has outer references to FROM list
          of the grouping query,
     then we substitute these outer references with
     Item_direct_ref like references under aggregate
     functions: Item_direct_ref obtains data directly
     from the current record.

2) The query with a non-trivial grouping expression like:

   SELECT (SELECT t1.a) aa, COUNT(DISTINCT b) c
   FROM t1 GROUP BY aa+0

also returned wrong result, since JOIN::exec() substitutes
references to top-level aliases in SELECT list with Item_copy
caching items. Item_copy items have same refreshing policy
as Item_ref items, so the whole groping expression with
Item_copy inside returns wrong result in filesort() and
end_send_group().

Fix: include aliased items into GROUP BY item tree instead
     of Item_ref references to them.

logging is disabled
      
The server would hit an assertion because of a DBUG violation.
There was a missing DBUG_RETURN and instead a plain return
was used.
      
This patch replaces the return with DBUG_RETURN.

into slow log
      
While processing a statement, down the mysql_parse execution
stack, the thd->enable_slow_log can be assigned to
opt_log_slow_admin_statements, depending whether one is executing
administrative statements, such as ALTER TABLE, OPTIMIZE,
ANALYZE, etc, or not. This can have an impact on slow logging for
statements that are executed after an administrative statement
execution is completed.
      
When executing statements directly from the user this is fine
because, the thd->enable_slow_log is reset right at the beginning
of the dispatch_command function, ie, everytime a new statement
is set is set to execute.
      
On the other hand, for slave SQL thread (sql_thd) the story is a
bit different. When in SBR the sql_thd applies statements by
calling mysql_parse. Right after, it calls log_slow_statement
function to log them if they take too long. Calling mysql_parse
directly is fine, but also means that dispatch_command function
is bypassed. As a consequence, thd->enable_slow_log does not get
a chance to be reset before the next statement to be executed by
the sql_thd. If the statement just executed by the sql_thd was an
administrative statement and logging of admin statements was
disabled, this means that sql_thd->enable_slow_log will be set to
0 (disabled) from that moment on. End result: sql_thd stops
logging slow statements.
      
We fix this by resetting the value of sql_thd->enable_slow_log to
the value of opt_log_slow_slave_statements right after
log_slow_stement is called by the sql_thd.

To 5.x Release
      
Notes
=====
      
This is a backport of BUG#23300 into 5.1 GA.
      
Original cset revid (in betony):
luis.soares@sun.com-20090929140901-s4kjtl3iiyy4ls2h

Description
===========
      
When using replication, the slave will not log any slow query
logs queries replicated from the master, even if the
option "--log-slow-slave-statements" is set and these take more
than "log_query_time" to execute.
                    
In order to log slow queries in replicated thread one needs to
set the --log-slow-slave-statements, so that the SQL thread is
initialized with the correct switch. Although setting this flag
correctly configures the slave thread option to log slow queries,
there is an issue with the condition that is used to check
whether to log the slow query or not. When replaying binlog
events the statement contains the SET TIMESTAMP clause which will
force the slow logging condition check to fail. Consequently, the
slow query logging will not take place.
                    
This patch addresses this issue by removing the second condition
from the log_slow_statements as it prevents slow queries to be
binlogged and seems to be deprecated.

Fixed 2 problems :
1. test_if_order_by_key() was continuing on the primary key
as if it has a primary key suffix (as the secondary keys do).
This leads to crashes in ORDER BY <pk>,<pk>.
Fixed by not treating the primary key as the secondary one
and not depending on it being clustered with a primary key.
2. The cost calculation was trying to read the records 
per key when operating on ORDER BYs that order on all of the 
secondary key + some of the primary key.
This leads to crashes because of out-of-bounds array access.
Fixed by assuming we'll find 1 record per key in such cases.

The problem was that the dbug facility was being used after the
per-thread dbug state had already been finalized. The was present
in a few functions which invoked decrement_handler_count, which
in turn invokes my_thread_end on Windows. In my_thread_end, the
per-thread dbug state is finalized. Any use after the state is
finalized ends up creating a new state.

The solution is to process the exit of a function before the
decrement_handler_count function is called.

The 'rpl_get_master_version_and_clock' test verifies if the slave I/O
thread tries to reconnect to master when it tries to get the values of
the UNIX_TIMESTAMP, SERVER_ID from master under network disconnection.
So the master server is restarted for making the transient network
disconnection, during the period the COM_REGISTER_SLAVE failures are
produced in server log file when the slave I/O thread tries to
register on master.

To fix the problem, suppress COM_REGISTER_SLAVE failures in server log
file by mtr suppression, because they are expected.

MySQL's hash functions MD5 and SHA relied on the somewhat slow 
sprintf function to convert the digests to hex representations.
This patch replaces the sprintf with a specific and inline hex
conversion function.

Patch contributed by Jan Steemann.

NOTE: added TODO to the comments requested by reviewer during this
      merge.

should be exited before destroying the thread local storage.

sql_udf.cc

Detailed revision comments:

r6471 | calvin | 2010-01-16 01:43:27 +0200 (Sat, 16 Jan 2010) | 4 lines
branches/5.1: fix bug#49396: main.innodb test fails in embedded mode

Change replace_result by using $MYSQLD_DATADIR. Tested in both embedded
mode and normal server mode.

removed wrongly introduced strlen calls

Detailed revision comments:

r6492 | sunny | 2010-01-21 09:38:35 +0200 (Thu, 21 Jan 2010) | 1 line
branches/5.1: Add reference to bug#47621 in the comment.

Detailed revision comments:

r6489 | sunny | 2010-01-21 02:57:50 +0200 (Thu, 21 Jan 2010) | 2 lines
branches/5.1: Factor out test for bug#44030 from innodb-autoinc.test
into a separate test/result files.

Detailed revision comments:

r6488 | sunny | 2010-01-21 02:55:08 +0200 (Thu, 21 Jan 2010) | 2 lines
branches/5.1: Factor out test for bug#44030 from innodb-autoinc.test
into a separate test/result files.

Detailed revision comments:

r6424 | marko | 2010-01-12 12:22:19 +0200 (Tue, 12 Jan 2010) | 16 lines
branches/5.1: In innobase_initialize_autoinc(), do not attempt to read
the maximum auto-increment value from the table if
innodb_force_recovery is set to at least 4, so that writes are
disabled. (Bug #46193)

innobase_get_int_col_max_value(): Move the function definition before
ha_innobase::innobase_initialize_autoinc(), because that function now
calls this function.

ha_innobase::innobase_initialize_autoinc(): Change the return type to
void.  Do not attempt to read the maximum auto-increment value from
the table if innodb_force_recovery is set to at least 4.  Issue
ER_AUTOINC_READ_FAILED to the client when the auto-increment value
cannot be read.

rb://144 by Sunny, revised by Marko

Detailed revision comments:

r6422 | marko | 2010-01-12 11:34:27 +0200 (Tue, 12 Jan 2010) | 3 lines
branches/5.1: Non-functional change:
Make innobase_get_int_col_max_value() a static function.
It does not access any fields of class ha_innobase.

Detailed revision comments:

r6421 | jyang | 2010-01-12 07:59:16 +0200 (Tue, 12 Jan 2010) | 8 lines
branches/5.1: Fix bug #49238: Creating/Dropping a temporary table
while at 1023 transactions will cause assert. Handle possible
DB_TOO_MANY_CONCURRENT_TRXS when deleting metadata in
row_drop_table_for_mysql().

rb://220, approved by Marko

In RBR, DDL statement will change binlog format to non row-based
format before it is binlogged, but the binlog format was not be
restored, and then manipulating a temporary table can not reset binlog
format to row-based format rightly. So that the manipulated statement
is binlogged with statement-based format.

To fix the problem, restore the state of binlog format after the DDL
statement is binlogged.

The WL#5154 commit added a couple of warning messages that
was not fixed in the result files for two RPL tests.

cant find record

Some engines return data for the record. Despite the fact that
the null bit is set for some fields, their old value may still in
the row. This can happen when unpacking an AI from the binlog on
top of a previous record in which a field is set to NULL, which
previously contained a value. Ultimately, this may cause the
comparison of records to fail when the slave is doing an index or
range scan.

We fix this by deploying a call to reset() for each field that is
set to null while unpacking a row from the binary log.
Furthermore, we also add mixed mode test case to cover the
scenario where updating and setting a field to null through a
Query event and later searching it through a rows event will
succeed.

Finally, we also change the reset() method, from Field_bit class,
so that it takes into account bits stored among the null bits and
not only the ones stored in the record.

Several items said to be deprecated in the 4.1 manual
have never been removed.  This worklog adds deprecation
warnings when these items are used, and warns the user 
that the items will be removed in MySQL 5.6.

A couple of previously deprecation decision have been
reversed (see single file comments)

3325 Magnus Blåudd    2010-01-05
     Bug #49860 new compiler warning ha_archive
      - fix compiler warning by casting to ulong 

3321 Magnus Blåudd    2010-01-05
     BUG#44840 - ndbapi compiler warning - type qualifier ignored for function return type
      - Remove the "const"
      - NOTE! This is an ABI incompatible change for some C++ compilers, NdbApi applications
        using any of the four changed functions may need a recompile if it's using dynamic linking.

It is well-known that due to concurrency issues, a slave can become
inconsistent when a transaction contains updates to both transaction and
non-transactional tables in statement and mixed modes.

In a nutshell, the current code-base tries to preserve causality among the
statements by writing non-transactional statements to the txn-cache which
is flushed upon commit. However, modifications done to non-transactional
tables on behalf of a transaction become immediately visible to other
connections but may not immediately get into the binary log and therefore
consistency may be broken.

In general, it is impossible to automatically detect causality/dependency
among statements by just analyzing the statements sent to the server. This
happen because dependency may be hidden in the application code and it is
necessary to know a priori all the statements processed in the context of
a transaction such as in a procedure. Moreover, even for the few cases that
we could automatically address in the server, the computation effort
required could make the approach infeasible.

So, in this patch we introduce the option
    - "--binlog-direct-non-transactional-updates" that can be used to bypass
    the current behavior in order to write directly to binary log statements
    that change non-transactional tables.

Missing ha_rnd_end in copy_partitions, found due to a
DBUG_ASSERT in mysql-pe

PB2 run uncovered issue that needs further analysis.

'CREATE TABLE IF NOT EXISTS ... SELECT' statement were causing 'CREATE
TEMPORARY TABLE ...' to be written to the binary log in row-based 
mode (a.k.a. RBR), when there was a temporary table with the same name.
Because the 'CREATE TABLE ... SELECT' statement was executed as 
'INSERT ... SELECT' into the temporary table. Since in RBR mode no 
other statements related to temporary tables are written into binary log,
this sometimes broke replication.

This patch changes behavior of 'CREATE TABLE [IF NOT EXISTS] ... SELECT ...'.
it ignores existence of temporary table with the 
same name as table being created and is interpreted
as attempt to create/insert into base table. This makes behavior of
'CREATE TABLE [IF NOT EXISTS] ... SELECT' consistent with
how ordinary 'CREATE TABLE' and 'CREATE TABLE ... LIKE' behave.

The optimizer must not continue executing the current query
if e.g. the storage engine reports an error.
This is somewhat hard to implement with Item::val_xxx()
because they do not have means to return error code.
This is why we need to check the thread's error state after
a call to one of the Item::val_xxx() methods.

Fixed store_key_item::copy_inner() to return an error state 
if an error happened during the call to Item::save_in_field() 
because it calls Item::val_xxx().
Also added similar checks to related places.

Added not_embedded to the new dbug_sync test file.

BUG#49481: RBR: MyISAM and bit fields may cause slave to stop on delete: 
cant find record
      
BUG#49482: RBR: Replication may break on deletes when MyISAM tables + 
char field are used

When using MyISAM tables, despite the fact that the null bit is
set for some fields, their old value is still in the row. This
can cause the comparison of records to fail when the slave is
doing an index or range scan.

We fix this by avoiding memcmp for MyISAM tables when comparing
records. Additionally, when comparing field by field, we first
check if both fields are not null and if so, then we compare
them. If just one field is null we return failure immediately. If
both fields are null, we move on to the next field.