Part 2. Function QUOTE() was not multi-byte safe.

  @ mysql-test/r/ctype_ucs.result
  @ mysql-test/t/ctype_ucs.test
  Adding tests

  @ sql/item_strfunc.cc
  Fixing Item_func_quote::val_str to be multi-byte safe.

  @ sql/item_strfunc.h
  Multiple size needed for quote characters to mbmaxlen

      
Problem: wrong character set pointer was passed to my_strtoll10_mb2,
which led to DBUG_ASSERT failure in some cases.

  @ mysql-test/r/func_encrypt_ucs2.result
  @ mysql-test/t/func_encrypt_ucs2.test
  @ mysql-test/r/ctype_ucs.result
  @ mysql-test/t/ctype_ucs.test
  Adding tests

  @ sql/item_func.cc
  "cs" initialization was wrong (res does not necessarily point to &str_value)

  @ sql/item_strfunc.cc
  Item_func_dec_encrypt::val_str() and Item_func_des_descrypt::val_str()
  did not set character set for tmp_value (the returned value),
  so the old value, which was previously copied from args[1]->val_str(),
  was incorrectly returned with tmp_value.

Bug#11765108 - Bug#58036: CLIENT UTF32, UTF16, UCS2 SHOULD BE DISALLOWED, THEY CRASH SERVER 

Fixing wrong usage of DBUG_ASSERT.
In non-debug version thd_init_client_charset
was not executed at all.

Bug#11769332 : These tests crash on windows which leads to cdb hang. This results in very long runtime. Disable till the bug is fixed

Bug#11769332 : Disable in daily runs till the bug is fixed. These tests crash the server abd can lead to cdb hang on windows

Post-merge fix: equal sign is now meaningless, the
string being printed was already preceded by a colon.

Result File Correction For Bug Fix

Problem: a byte behind the end of input string was read
in case of a broken XML not having a quote or doublequote
character closing a string value.

Fix: changing condition not to read behind the end of input string

  @ mysql-test/r/xml.result
  @ mysql-test/t/xml.test
  Adding tests

  @ strings/xml.c
  When checking if the closing quote/doublequote was found,
  using p->cur[0] us unsafe, as p->cur can point to the byte after the value.
  Comparing p->cur to p->beg instead.

Problem: in case of string CASE/WHEN arguments with different
character sets, Item_func_case::find_item() called comparator
cmp_items[x] on mixed character set Items, so a 8-bit value could
be errouneously referenced to as being utf16/utf32 value,
which led to crash on DBUG_ASSERT() because of wrong value length.
This was wrong, as string comparator expects arguments in the same
character set.

Fix: modify Item_func_case's argument list after calling
agg_arg_charsets_for_comparison() - put the Items in "agg" array
back to "args", because some of the Items in the "agg" array might
have been changed to character set converters:
- to Item_func_conv_charset for non-constant items
- to Item_string for constant items

In other words, perform the same substitution which is done in
all other operations string comparison or string result operations:

Replace
  CASE         latin1_item              WHEN utf16_item THEN ... END
to
  CASE CONVERT(latin1_item USING utf16) WHEN utf16_item THEN ... END

Replace
  CASE utf16_item WHEN         latin1_item              THEN ... END
to
  CASE utf16_item WHEN CONVERT(latin1_item USING utf16) THEN ... END


  @ mysql-test/r/ctype_utf16.result
  @ mysql-test/r/ctype_utf32.result
  @ mysql-test/t/ctype_utf16.test
  @ mysql-test/t/ctype_utf32.test
  Adding tests

  @ sql/item_cmpfunc.cc
  Put "agg" back to "args".

  @ sql/sql_string.cc
  Backporting a fix for String::set_or_copy_aligned() from 5.6,
  for better test coverage:
  "SELECT _utf16 0x61" should expand the string to 0x0061 rather
  than to 0x000061.
  This fix was made in 5.6 under terms of "WL#4616 Implement UTF16-LE".

Bug#11763065 - 55730: KILL_SERVER() CALLS SETEVENT ON A NULL 
               HANDLE, SMEM_EVENT_CONNECT_REQUEST
      
Application Verifier is a Microsoft tool used for
detecting certain classes of programming errors.
In particular, MS Windows OS resource usage is
monitored for wrong usage (handles, thread local
storage, critical sections, ...)
      
In MySQL 5.5.x, an error was introduced where an
object on thread local storage was used before the
TLS and the object was created.
      
The fix has been to move the mysys initialization
to an earlier stage in the boot process when built for
Windows.  For non-win builds, the init already happens
early.

Some un-tangling of calls to my_init(), my_basic_init()
and my_thread_global_init() was done.  There is no
longer a need to do init in steps, so the full my_init()
is called instead of my_init_basic().
      
In addition,  Bug#11763065 was fixed.  The event handle
'smem_event_connect_request' is only created if
'opt_enable_shared_memory' is set.  When killing the
server, an event was flagged on the handle
unconditionally.  Added a test, so it will only be
flagged if created.

IS FAILING".

The problem was that large_tests.lock_tables_big test was
failing due to exceeding open files limit on platforms where
this limit was set too low (this test simultaneously opens
approx. 6000 files).

This patch solves this issue by ensuring that this test is
skipped on such platforms.

Assertion `bitmap_is_set_all(&table->s->all_set)' failed in
handler::ha_reset

Post-push fix for unit test compilation error on Windows.

the trunk.

in 5.5 and trunk. First we remove the file in the commit.

Bug #11766501: Multiple RBS break the get rseg with mininum trx_t::no code during purge
      
Bug# 59291 changes:
      
Main problem is that truncating the UNDO log at the completion of every
trx_purge() call is expensive as the number of rollback segments is increased.
We truncate after a configurable amount of pages. The innodb_purge_batch_size
parameter is used to control when InnoDB does the actual truncate. The truncate
is done once after 128 (or TRX_SYS_N_RSEGS iterations). In other words we
truncate after purge 128 * innodb_purge_batch_size. The smaller the batch
size the quicker we truncate.
      
Introduce a new parameter that allows how many rollback segments to use for
storing REDO information. This is really step 1 in allowing complete control
to the user over rollback space management.
      
New parameters:
    i) innodb_rollback_segments = number of rollback_segments to use
       (default is now 128) dynamic parameter, can be changed anytime.
       Currently there is little benefit in changing it from the default.
      
Optimisations in the patch.
      
    i. Change the O(n) behaviour of trx_rseg_get_on_id() to O(log n)
       Backported from 5.6. Refactor some of the binary heap code.
       Create a new include/ut0bh.ic file.
      
    ii. Avoid truncating the rollback segments after every purge.
      
Related changes that were moved to a separate patch:
      
    i. Purge should not do any flushing, only wait for space to be free so that
       it only does purging of records unless it is held up by a long running
       transaction that is preventing it from progressing.
      
   ii. Give the purge thread preference over transactions when acquiring the
       rseg->mutex during commit. This to avoid purge blocking unnecessarily
       when getting the next rollback segment to purge.
      
Bug #11766501 changes:
      
Add the rseg to the min binary heap under the cover of the kernel mutex and
the binary heap mutex. This ensures the ordering of the min binary heap.
      
The two changes have to be committed together because they share the same
that fixes both issues.
      
rb://567 Approved by: Inaam Rana.

              UPDATES THE TABLE ENTRIES (formerly 55385)
BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND 
              IF A TABLE IS UPDATED TWICE (formerly 57373)
            
If multiple-table update updates a row through two aliases and
the first update physically moves the row, the second update will
fail to locate the row. This results in different errors
depending on storage engine:
  * MyISAM: Got error 134 from storage engine
  * InnoDB: Can't find record in 'tbl'
None of these errors accurately describe the problem. 
      
Furthermore, since MyISAM is non-transactional, the update
executed first will be performed while the second will not.
In addition, for two equal multiple-table update statements,
one could succeed and the other fail based on whether or not
the record actually moved or not. This was inconsistent.
      
Two update operations may physically move a row:
  1) Update of a column in a clustered primary key
  2) Update of a column used to calculate which partition the 
     row belongs to
           
BUG#11764529 is about case 1) above, BUG#11762751 was about case 2).
      
The fix for these bugs is to return with an error if multiple-table 
update is about to:
  a) Update a table through multiple aliases, and
  b) Perform an update that may physically more the row 
     in at least one of these aliases
    
This avoids 
  * partial updates as described for MyISAM above,
  * provides the same error message that describes the actual problem
    for all SEs
  * inconsistent behavior where a statement fails or succeeds based on
    e.g. the partitioning algorithm of the table.

The problem was that doing ALTER TABLE on a table which had a key
on a TEXT/BLOB column with a prefix longer than the maximum number
of characteres in this column (as per the character set), by mistake,
caused an error (Error 1170 - ER_BLOB_KEY_WITHOUT_LENGTH).

This bug not repeatable in 5.5.

This patch adds a regression test to alter_table.test and
contains no code changes.

Remove last traces of HAVE_NDBCLUSTER_DB define - it has not had an effect in a long time and is just confusing.
At the same time backport the removal of OPT_NDB_CONNECTSTRING and OPT_NDBCLUSTER values from "enum options_client"

               ("-") IN DATABASE NAMES IN ALTER DATABASE.

mysqldump did not quote database name in 'ALTER DATABASE'
statements in its output. This can further cause a failure
while loading if database name contains a hyphen '-'.

This happened as, while printing the 'ALTER DATABASE'
statements, the database name was not quoted.

Fixed by quoting the database name.