MYSQLDUMP OUTPUT
      
      A patch is pushed on this bug. A result mismatch
      occured for the test main.ddl_i18n_utf8 in
      x86_64 gcov build of linux in pb2. This commit is
      to modify ddl_i18n_utf8.result to match the
      changes made for the bug.

             MYSQLDUMP OUTPUT

A patch is pushed on this bug. A result mismatch
occured for the test main.ddl_i18n_koi8r in
x86_64 gcov build of linux in pb2. This commit is
to modify ddl_i18n_koi8r.result to match the
changes made for the bug.

             MYSQLDUMP OUTPUT

Problem: mysqldump when used with option --routines, dumps
         all the routines of the specified database into
         output. The statements in this output are written
         in such a way that they are version safe using C
         style version commenting (of the format
         /*!<version num> <sql statement>*/). If a semicolon
         is present right before closing of the comment in
         dump output, it results in a syntax error while
         importing.


Solution: Version comments for dumped routines are
          specifically to protect the ones older than 5.0.
          When the import is done on 5.0 or later versions,
          entire create statement gets executed as all the
          check conditions at the beginning of the comments
          are cleared. Since the trade off is between the
          performance of newer versions which are more in
          use and protection of very old versions which are
          no longer supported, it is proposed that these
          comments be removed altogether to maintain
          stability of the versions supported.

This bug is fixed by Bug#14251529. Only testcase from the 
contribution is used.

rb://1546
approved by: Sunny Bains and Marko Makela

Our dealing of buf_page_t::access_time flag is inaccurate.
* If LRU eviction has not started we don't set the access_time
* If LRU eviction is started we set it only if the block is not
'too old'.
* Not a correctness issue but we hold buf_pool::mutex when
setting the flag

This patch fixes this by:
* Setting flag unconditionally whenever the first page access happens
* Use buf_page_t mutex to protect write to the flag

              INC_HOST_ERRORS() IS CALLED.

Description: Null merge from 5.1 to 5.5

No commit message

Remove a bogus debug assertion.

CHAR(n) in ROW_FORMAT=REDUNDANT tables is always fixed-length
(n*mbmaxlen bytes), but in the temporary file it is variable-length
(n*mbminlen to n*mbmaxlen bytes) for variable-length character sets,
such as UTF-8.

The temporary file format used during index creation and online ALTER
TABLE is based on ROW_FORMAT=COMPACT. Thus, it should use the
variable-length encoding even if the base table is in
ROW_FORMAT=REDUNDNAT.

dtype_get_fixed_size_low(): Replace an assertion-like check with a
debug assertion.

rec_init_offsets_comp_ordinary(), rec_convert_dtuple_to_rec_comp():
Make this an inline function.  Replace 'ulint extra' with 'bool temp'.

rec_get_converted_size_comp_prefix_low(): Renamed from
rec_get_converted_size_comp_prefix(), and made inline. Add the
parameter 'bool temp'. If temp=true, do not add REC_N_NEW_EXTRA_BYTES.

rec_get_converted_size_comp_prefix(): Remove the comment about
dict_table_is_comp(). This function is only to be called for other
than ROW_FORMAT=REDUNDANT records.

rec_get_converted_size_temp(): New function for computing temporary
file record size. Omit REC_N_NEW_EXTRA_BYTES from the sizes.

rec_init_offsets_temp(), rec_convert_dtuple_to_temp(): New functions,
for operating on temporary file records.

rb:1559 approved by Jimmy Yang

 - no need to use --skip-ndb in collections files anymore, since long but
  more clear logic after recent mtr.pl fixes. ndb tests are never run in MySQL Server
  unless explicitly requested
 - remove sys_vars.ndb_log_update_as_write_basic.test and sys_vars.ndb_log_updated_only_basic.result since MySQL Server does not have those
  options.
 - Only sys_vars.have_ndbcluster_basic left since MySQL Server has that variable hardcoded.

No commit message

When master and slave have different schemas, in particular different
AUTO_INCREMENT columns, INSERT_ID events logged for a given table on
master may be applied to a different table on slave on SBR, e.g.:
  master has one table (t1) with one auto-inc column and another table
  (t2) without auto-inc column, on slave t1 does not have auto-inc
  column (despite having the same columns) and t2 has a auto-inc
  column. The INSERT_ID that is intended for t1, since t1 on slave
  doesn't have auto-inc column is used on t2, causing consistency
  problems.

To fix this incorrect behaviour, auto-inc interval allocation via
INSERT_ID is made effectively terminated at the end of top-level
statements on slave and binlog replay.

Problem description: Incorrect key file. Key file is corrupted,
while reading the keys from the file. The problem here is that 
keyseg->start (which should point to the beginning of a field) 
is pointing beyond total record length.

Fix: If keyseg->start is greater than total record length then 
return error.

No commit message

No commit message

No commit message

rb://1411 approved by Marko

No commit message

No commit message

The problem is related to the changes made in bug#13025132.
get_partition_set can do dynamic pruning which limits the partitions
to scan even further. This is not accounted for when setting
the correct start of the preallocated record buffer used in
the priority queue, thus leading to wrong buffer is used
(including wrong preset partitioning id, connected to that buffer).

Solution is to fast forward the buffer pointer to point to the correct
partition record buffer.

The problem is related to the changes made in bug#13025132.
get_partition_set can do dynamic pruning which limits the partitions
to scan even further. This is not accounted for when setting
the correct start of the preallocated record buffer used in
the priority queue, thus leading to wrong buffer is used
(including wrong preset partitioning id, connected to that buffer).

Solution is to fast forward the buffer pointer to point to the correct
partition record buffer.

btr_lift_page_up() writes wrong page number (different by -1) for upper than father page.
But in almost all of the cases, the father page should be root page, no upper
pages. It is very rare path.

In addition the leaf page should not be lifted unless the father page is root.
Because the branch pages should not become the leaf pages.

rb://1336 approved by Marko Makela.

from MySQL 5.6 into MySQL 5.5

Will close Bug#14515889 BACKPORT OF INNODB DEADLOCK LOGGING TO 5.5

The original implementation is in
vasil.dimov@oracle.com-20101213120811-k2ldtnao2t6zrxfn

Approved by:	Jimmy (rb:1535)

btr_lift_page_up() writes wrong page number (different by -1) for upper than father page.
But in almost all of the cases, the father page should be root page, no upper
pages. It is very rare path.

In addition the leaf page should not be lifted unless the father page is root.
Because the branch pages should not become the leaf pages.

rb://1336 approved by Marko Makela.

No commit message

Problem description: Corrupt key file for the table. Size of the 
key is greater than the maximum specified size. This results in 
the overflow of the key buffer while reading the key from key 
file.

Fix: If size of key is greater than the maximum size it returns 
an error before writing it into the key buffer. Gives error as 
corrupt file but no stack overflow.

When a new primary key is added to an InnoDB table, then the following
steps are taken by InnoDB plugin:

.  let t1 be the original table.
.  a temporary table t1@00231 will be created by cloning t1.
.  all data will be copied from t1 to t1@00231.
.  rename t1 to t1@00232.
.  rename t1@00231 to t1.
.  drop t1@00232.

The rename and drop operations involve file operations.  But file operations
cannot be rolled back.  So in row_merge_rename_tables(), just after doing data
dictionary update and before doing any file operations, generate redo logs
for file operations and commit the transaction.  This will ensure that any
crash after this commit, the table is still recoverable by moving .ibd and
.frm files.  Manual recovery is required.

During recovery, the rename file operation redo logs are processed.
Previously this was being ignored.

rb://1460 approved by Marko Makela.

              TABLE DATA IF DUMPS MYSQL DATABA
Problem: If mysqldump is run without --events (or with --skip-events)
it will not dump the mysql.event table's data. This behaviour is inconsistent
with that of --routines option, which does not affect the dumping of
mysql.proc table. According to the Manual, --events (--skip-events) defines,
if the Event Scheduler events for the dumped databases should be included
in the mysqldump output and this has nothing to do with the mysql.event table
itself.
Solution: A warning has been added when mysqldump is used without --events 
(or with --skip-events) and a separate patch with the behavioral change 
will be prepared for 5.6/trunk.