temp table
            
This patch introduces two key changes in the replication's behavior.
            
Firstly, it reverts part of BUG#51894 which puts any update to temporary tables
into the trx-cache. Now, updates to temporary tables are handled according to
the type of their engines as a regular table.
            
Secondly, an unsafe mixed statement, (i.e. a statement that access transactional
table as well non-transactional or temporary table, and writes to any of them),
are written into the trx-cache in order to minimize errors in the execution when
the statement logging format is in use.
            
Such changes has a direct impact on which statements are classified as unsafe
statements and thus part of BUG#53259 is reverted.

Problem: a few functions did not calculate their max_length correctly.
This is an after-fix for WL#2649 Number-to-string conversions".

Fix: changing the buggy functions to calculate max_length
using fix_char_length() introduced in WL#2649,
instead of setting max_length directly

  mysql-test/include/ctype_numconv.inc
     Adding new tests

  mysql-test/r/ctype_binary.result
     Adding new tests

  mysql-test/r/ctype_cp1251.result
     Adding new tests

  mysql-test/r/ctype_latin1.result
     Adding new tests

  mysql-test/r/ctype_ucs.result
     Adding new tests

  mysql-test/r/ctype_utf8.result
     Adding new tests

  mysql-test/t/ctype_utf8.test
    Including ctype_numconv

  sql/item.h
    - Introducing new method fix_char_length_ulonglong(),
    for the cases when length is potentially greater
    than UINT_MAX32. This method removes a few
    instances of duplicate code, e.g. in item_strfunc.cc.
    - Setting collation in Item_copy properly. This change
    fixes wrong metadata on client side in some cases, when
    "binary" instead of the real character set was reported.

  sql/item_cmpfunc.cc
    - Using fix_char_length() and max_char_length() methods,
    instead of direct access to max_length, to calculate
    item length properly.
    - Moving count_only_length() in COALESCE after
    agg_arg_charsets_for_string_result(). The old
    order was incorrect and led to wrong length
    calucation in case of multi-byte character sets.
    
  sql/item_func.cc
    Fixing that count_only_length() didn't work
    properly for multi-byte character sets.
    Using fix_char_length() and max_char_length()
    instead of direct access to max_length.

  sql/item_strfunc.cc
    - Using fix_char_length(), fix_char_length_ulonglong(),
    max_char_length() instead of direct access to max_length.
    - Removing wierd condition: "if (collation.collation->mbmaxlen > 0)",
    which is never FALSE.

from mysql-trunk-bugfixing (5.6.1-m5) from mysql-5.5-bugfixing (5.5.6-m3).

Problem: Item_func_hex::val_str() returned data in ASCII format,
which did not match collation.collation pointing to my_charset_utf32_general_ci.
Fix: changing parent class of Item_func_hex to Item_str_ascii_func,
as val_str() implementation is heavily ASCII-oriented.

  mysql-test/r/ctype_utf32.result
  mysql-test/t/ctype_utf32.test
  Adding test case


  sql/item_strfunc.cc
  sql/item_strfunc.h
  - Changing parent class to Item_str_ascii_func
  - Clean-up in Item_func_hex::fix_length_and_dec()
    Using fix_char_length() instead of setting max_length directly.

        'CREATE TABLE IF NOT EXISTS ... SELECT' behaviour
BUG#47132, BUG#47442, BUG49494, BUG#23992 and BUG#48814 will disappear
automatically after the this patch.
BUG#55617 is fixed by this patch too.
            
This is the 5.5 part.
It implements:
- 'CREATE TABLE IF NOT EXISTS ... SELECT' statement will not insert
  anything and binlog anything if the table already exists.
  It only generate a warning that table already exists.
- A couple of test cases for the behavior changing.

dict_load_index_low(): Rename the parameter "cached" to "allocated"
and clarify the comments.

Followup to vasil.dimov@oracle.com-20100817063430-inglmzgdtj95t29d
which didn't fully fix the test because the order of the returned
rows was different in embedded and non-embedded version. So the only
way to fix this is to add an ORDER BY clause.

lock wait time. Including the InnoDB lock time in the exiting "Lock_time"
output.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm. The endspace test is non-deterministic
because it does not include ORDER BY clause in its queries.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm.

  
This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm.

This is a followup to vasil.dimov@oracle.com-20100816142329-yimenbuktd416z1a
which improved the sampling algorithm. I have manually checked that the new
values are actually the correct ones, for example:
-rows	16
+rows	32
the number of rows returned by the query is 32.

Improve the range estimation algorithm.

Previously:
For a given level the algo knows the number of pages in the requested range and the n

With this change:
Same idea, but peek a few (10) of the intermediate pages to get a better estimate of 

In the bug report one of the examples has a btree with a snippet of the leaf level li
page1(899 records), page2(1 record), page3(1 record), page4(1 record)
so when trying to estimate, the previous algo, assumed there are average (899+1)/2=45
Fix Bug#53761 RANGE estimation for matched rows may be 200 times different

Improve the range estimation algorithm.

Previously:
For a given level the algo knows the number of pages in the requested range
and the number of records on the leftmost and the rightmost page. Then it
assumes all pages in between contain the average between the two border pages
and multiplies this average number by the number of intermediate pages.

With this change:
Same idea, but peek a few (10) of the intermediate pages to get a better
estimate of the average number of records per page. If there are less than 10
intermediate pages then all of them will be scanned and the result will be
precise, not an estimation.

In the bug report one of the examples has a btree with a snippet of the leaf
level like this:
page1(899 records), page2(1 record), page3(1 record), page4(1 record)
so when trying to estimate, the previous algo, assumed there are average
(899+1)/2=450 records per page which went terribly wrong. With this change
page2 and page3 will be read and the exact number of records will be returned.

Approved by:	Sunny (rb://401)

           locks on the table

Fixing the partitioning specifics after TRUNCATE TABLE in
bug-42643 was fixed.

Reorganize of code to decrease the size of the giant switch
in mysql_execute_command, and to prepare for future parser
reengineering. Moved code into Sql_statement objects.

Updated patch according to davi's review comments.

pushdown.
      
NDB supports only a limited set of item nodes for use in engine condition
pushdown. Because of this adding cache for const expression effectively
disabled this optimization.
      
The ndb_serialize_cond function is extended to support Item_cache and treat
it as a constant values.
A helper function called ndb_serialize_const is added. It is used to create
Ndb_cond value node from given const item.

Note that this was originally pushed by Calvin but the was later
reverted by mistake.

bug#54702

           corruption on ADD PARTITION and LOCK TABLE
Bug#53770: Server crash at handler.cc:2076 on
           LOAD DATA after timed out COALESCE PARTITION

5.5 fix for:
Bug#51042: REORGANIZE PARTITION can leave table in an
           inconsistent state in case of crash
Needs to be back-ported to 5.1

5.5 fix for:
Bug#50418: DROP PARTITION does not interact with
           transactions

Main problem was non-persistent operations done
before meta-data lock was taken (53770+53676).
And 53676 needed to keep the table/partitions opened and locked
while copying the data to the new partitions.

Also added thorough tests to spot some additional bugs
in the ddl_log code, which could result in bad state
between the .frm and partitions.

Collapsed patch, includes all fixes required from the reviewers.

Fixing copyright text.

      
Removed table SETUP_OBJECTS.
      
Renamed table PROCESSLIST to THREADS.
      
Renamed table EVENTS_WAITS_SUMMARY_BY_EVENT_NAME
to EVENTS_WAITS_SUMMARY_GLOBAL_BY_EVENT_NAME.
      
Adjusted Makefiles, code and tests accordingly.

Disable the GCC visibility attribute on all sun platforms.

Approved by Marko on IRC.

  "MySQL server is not restarted properly after RPM upgrade"

The problem is that with the general spec file cleanup and
alignment we also did a name change, dropping the "-community"
part from the package file name.

As a result of this, RPM (some versions of it) will report
file conflicts, because it considers this name difference
to imply different packages.
To avoid this, the spec file explicitly "obsoletes" the old
packages (with "-community" in the file name).

Now, RPM will first install these packages and the remove the
old ones, and part of that removal is running the "%preun"
section which stops the server and uninstalls the service
(removes the symlinks to "/etc/init.d/mysql" from the run
level directories).
This stop/uninstall will affect the new server!

The fix is to define a "%triggerpostun" in this spec file
which will watch for removal of the "-community" server.
If this is done (as part of this install/upgrade), the
trigger code will re-install the service and restart the
server process.

In addition, the "sleep" calls after starting the server
have been cleaned up: Rather than doing 2* "sleep 2",
it is now 1 "sleep 5".

it couldn't parse the --ssl option.