we don't have closed-source plugins

This patch allows up to 64K pages for tables with DYNAMIC, COMPACT 
and REDUNDANT row types. Tables with COMPRESSED row type allows 
still only <= 16K page size. Note that single row size must be
still <= 16K and max key length is not affected.

XtraDB 5.6.16-64.2

InnoDB 5.6.16

revno: 5716
committer: Praveenkumar Hulakund <praveenkumar.hulakund@oracle.com>
branch nick: mysql_5_6
timestamp: Sat 2013-12-28 22:08:40 +0530
message:
  Bug#17862905: MYSQLDUMP CREATES USELESS METADATA LOCKS

MDEV-6095 replicate- filters for slaves with a connection name that contain an underscore are ignored

Revert revision-id: guilhem@mysql.com-20091118203617-3jfudef971r7bf2y
Implement a non-destructive fix instead.

various places in the code.

the linker script.

correct the length encoding for the extra2 frm segment. add the comment.

Fixed bug on function call when InnoDB plugin is used.

Replication caches the character sets used in a query, to be able to quickly
reuse them for the next query in the common case of them not having changed.

In parallel replication, this caching needs to be per-worker-thread. The
code was not modified to handle this correctly, so the caching in one worker
could cause another worker to run a query using the wrong character set,
causing replication corruption.

            I_S table

mdl_iterate() helper function (which is used by the plugin to iterate mdl
locks) acquired mutexes in reverse order.

Fixed by iterating MDL locks in two stages:
1. Iterate locks hash under the protection of hash mutex, store all
   lock pointers in a thread local array and increment reference counter
   for the lock.
2. Iterate local array without protection of hash mutex, handle destroyed
   locks.

It somewhat echoes hack in MDL_map_partition::move_from_hash_to_lock_mutex.

- Use floating-point division in selectivity calculations.

The problem appeared when a loose scan used a key prefix whose
last component called uint3korr in the implementation of the key_cmp
virtual function.

- Testcase. The bug is fixed by commit for MDEV-6003

- Fix table_cond_selectivity() to work correctly for ref access 
  and "keypart2=const" case.

MDEV-5980: EITS: if condition is used for REF access, its selectivity is still in filtered%
MDEV-5985: EITS: selectivity estimates look illogical for join and non-key equalities
MDEV-6003: EITS: ref access, keypart2=const vs keypart2=expr - inconsistent filtered% value
- Made a number of fixes in table_cond_selectivity() so that it returns
  correct selectivity estimates.
- Added comments in related code.
Better comments