failures on sparc64.

file .\item_subselect.cc, line 836

IN quantified predicates are never executed directly. They are rather wrapped
inside nodes called IN Optimizers (Item_in_optimizer) which take care of the
execution. However, this is not done during query preparation. Unfortunately
the LIKE predicate pre-evaluates constant right-hand side arguments even
during name resolution. Likely this is meant as an optimization.

Fixed by not pre-evaluating LIKE arguments in view prepare mode.

Reverted the ulong->uint diff
Re-applied the first diff.
The original commit message follows:

enum plugin system variables are ulong internally, not int.
On systems where long is not the same as an int it causes
problems. 
Fixed by correct typecasting. Removed the test from the 
experimental list.

The enum system variables were handled inconsistently 
as ints, unsigned int and unsigned long on various places.
This caused problems on platforms on which 
sizeof(int) != sizeof(long).
Fixed by homogenizing the type of the enum variables
to unsigned int, since it's size compatible with the C enum
type. 
Removed the test from the experimental list.

Post fix

With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.

To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.

Fix compiler warnings.

mostly because existing test result files were not updated.

In order to be able to check if the set of the grouping fields in a 
GROUP BY has changed (and thus to start a new group) the optimizer
caches the current values of these fields in a set of Cached_item 
derived objects.
The Cached_item_str, used for caching varchar and TEXT columns,
is limited in length by the max_sort_length variable.
A String buffer to store the value with an alloced length of either
the max length of the string or the value of max_sort_length 
(whichever is smaller) in Cached_item_str's constructor.
Then, at compare time the value of the string to compare to was 
truncated to the alloced length of the string buffer inside 
Cached_item_str.
This is all fine and valid, but only if you're not assigning 
values near or equal to the alloced length of this buffer.
Because when assigning values like this the alloced length is 
rounded up and as a result the next set of data will not match the
group buffer, thus leading to wrong results because of the changed
alloced_length.
Fixed by preserving the original maximum length in the 
Cached_item_str's constructor and using this instead of the 
alloced_length to limit the string to compare to.
Test case added.

Fix a regression (due to a typo) which caused spurious incorrect
argument errors for long data stream parameters if all forms of
logging were disabled (binary, general and slow logs).

Fix a regression (due to a typo) which caused spurious incorrect
argument errors for long data stream parameters if all forms of
logging were disabled (binary, general and slow logs).

With statement- or mixed-mode logging, "LOAD DATA INFILE" queries
are written to the binlog using special types of log events.
When mysqlbinlog reads such events, it re-creates the file in a
temporary directory with a generated filename and outputs a
"LOAD DATA INFILE" query where the filename is replaced by the
generated file. The temporary file is not deleted by mysqlbinlog
after termination.

To fix the problem, in mixed mode we go to row-based. In SBR, we
document it to remind user the tmpfile is left in a temporary
directory.

The problem is that the fix Bug#29784 was mistakenly
reverted when updating YaSSL to a newer version.

The solution is to re-apply the fix and this time
actually add a meaningful test case so that possible
regressions are caught.

Problem: The original patch didn't compile on debug_werror
due to wrong format in printf("%d") for size_t variables.

Fix: Adding cast to (int).

/*![:version:] Query Code */, where [:version:] is a sequence of 5 
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those 
servers whose versions are larger than the version appearing in the 
comment. It leads to a security issue when slave's version is larger 
than master's. A malicious user can improve his privileges on slaves. 
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.

This bug is fixed with the logic below: 
- To replace '!' with ' ' in the magic comments which are not applied on
  master. So they become common comments and will not be applied on slave.

- Example:
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
  will be binlogged as
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/

to mysql-5.1-innodb plugin.

Do not attempt to test the innodb plugin with the embedded server,
it's not supported for now.

Problem: The functions my_like_range_xxx() returned
badly formed maximum strings for Asian character sets,
which made problems for storage engines.

Fix: 
- Removed a number my_like_range_xxx() implementations,
  which were in fact dumplicate code pieces.
- Using generic my_like_range_mb() instead.
- Setting max_sort_char member properly for Asian character sets
- Adding unittest/strings/strings-t.c, 
  to test that my_like_range_xxx() return well-formed 
  min and max strings.

Notes:

- No additional tests in mysql/t/ available.
  Old tests cover the affected code well enough.

InnoDB Plugin 1.0.10 has been released with MySQL 5.1.49.

Bug#49542 - Do as the comment suggests and downgrade directory errors from find_file() to a warning unless they happen during a SHOW command.

SHOW DATABASES LIKE ... was not converting to lowercase on comparison as the
documentation is suggesting. 
Fixed it to behave similarly to SHOW TABLES LIKE ... and updated the failing
on MacOSX lowercase_table2 test case.

to write into a closed socket

Fix warnings flagged by the new warning option -Wunused-but-set-variable
that was added to GCC 4.6 and that is enabled by -Wunused and -Wall. The
option causes a warning whenever a local variable is assigned to but is
later unused. It also warns about meaningless pointer dereferences.

           due to GCC preprocessor change
      
The problem is that newer GCC versions treats missing headers
as fatal errors. The solution is to use a guard macro to prevent
the inclusion of system headers when checking the ABI with the
C Preprocessor.

Reference: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15638
           http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44836

           table with active trx

Essentially, the problem is that InnoDB does a implicit commit
when a cursor (table handler) is unlocked/closed, creating
a dissonance between the transaction state within the server
layer and the storage engine layer. Theoretically, a statement
transaction can encompass several table instances in a similar
manner to a multiple statement transaction, hence it does not
make sense to limit a statement transaction to the lifetime of
the table instances (cursors) used within it.

Since this particular instance of the problem is only triggerable
on 5.1 and is masked on 5.5 due 2PC being skipped (assertion is in
the prepare phase of a 2PC), the solution (which is less risky) is
to explicitly end the transaction before the cached table is unlock
on rename table.

The patch is to be null merged into trunk.

Problem: when SHOW BINLOG EVENTS was issued, it increased the value of
@@session.max_allowed_packet. This allowed a non-root user to increase
the amount of memory used by her thread arbitrarily. Thus, it removes
the bound on the amount of system resources used by a client, so it
presents a security risk (DoS attack).

Fix: it is correct to increase the value of @@session.max_allowed_packet
while executing SHOW BINLOG EVENTS (see BUG 30435). However, the
increase should only be temporary. Thus, the fix is to restore the value
when SHOW BINLOG EVENTS ends.
The value of @@session.max_allowed_packet is also increased in
mysql_binlog_send (i.e., the binlog dump thread). It is not clear if this
can cause any trouble, since normally the client that issues
COM_BINLOG_DUMP will not issue any other commands that would be affected
by the increased value of @@session.max_allowed_packet. However, we
restore the value just in case.