Bugfix for 53290, fast unique index creation fails on duplicate null values

    Summary:
    Bug in the fast index creation code incorrectly considers null
    values to be duplicates during block merging.  Innodb policy is that
    multiple null values are allowed in a unique index.  Null duplicates
    were correctly ignored while sorting individual blocks and with slow
    index creation.

    Test Plan:
    mtr, including new test, load dbs using deferred index creation

    DiffCamp Revision: 110840
    Reviewed By: mcallaghan
    CC: mcallaghan, mysql-devel@lists
    Revert Plan:
    OK

Allow multiple indexes to be dropped. (Bug #53256)

are different in 5.1 comparing to that of 5.5, so a hand port is
necessary to avoid wrong default option to be set by a simple
branch merge.

buf_flush_insert_into_flush_list(),
buf_flush_insert_sorted_into_flush_list(),
buf_flush_post_to_doublewrite_buf(): Check that the page is initialized.

buf_flush_insert_into_flush_list(),
buf_flush_insert_sorted_into_flush_list(),
buf_flush_post_to_doublewrite_buf(): Check that the page is initialized.

would get the block, new_block in the wrong order.
Fixing that would have complicated the function even further
for this marginal case.

When split_rec==NULL, choose the correct node pointer key (first_rec).

buf_page_get_gen(): Assert that buf_zip_decompress() succeeds.
Callers are not prepared for a NULL return value. (Bug #53248)

mysql-tests because those emit (spurious?) valgrind warnings.

This addresses Bug #53122 in the built-in InnoDB.

recv_addr_t: Turn space,page_no into bitfields to save space on 64-bit.
This addresses Bug #53122 in the InnoDB Plugin.

READ COMMITTED in the built-in InnoDB. (Bug #48607)

READ COMMITTED in the InnoDB Plugin. (Bug #48607)

on same table

Followup to vasil.dimov@oracle.com-20100428102033-dt3caf531rs3lidr :

Add more asserions, which I forgot.

This is branches/zip@r6032 in SVN and _is part_ of
revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:6113
in BZR.

This is being reverted because now the code is serialized directly on
index->stat_n_diff_key_vals[] as the fix for
Bug#53046 dict_update_statistics_low can still be run concurrently on same table
goes.

Address Marko's suggestions wrt the fix of
Bug#53046 dict_update_statistics_low can still be run concurrently
on same table

on same table

Protect dict_index_t::stat_n_diff_key_vals[] with an array of
mutexes.

Testing: tested all code paths under UNIV_SYNC_DEBUG
for the one in dict_print() one has to enable the InnoDB table monitor:
CREATE TABLE innodb_table_monitor (a int) ENGINE=INNODB;

  ------------------------------------------------------------------------
  r6103 | marko | 2009-10-26 15:46:18 +0200 (Mon, 26 Oct 2009) | 4 lines
  Changed paths:
     M /branches/zip/row/row0ins.c

  branches/zip: row_ins_alloc_sys_fields(): Zero out the system columns
  DB_TRX_ID, DB_ROLL_PTR and DB_ROW_ID, in order to avoid harmless
  Valgrind warnings about uninitialized data.  (The warnings were
  harmless, because the fields would be initialized at a later stage.)
  ------------------------------------------------------------------------

any files.

this results in some valgrind errors.

Bug#53202 valgrind: uninitialized bytes in dtuple_print()
has been opened to track this.

Extract part of innodb.innodb into innodb.innodb_misc1

This is needed in order to be able to more easily debug this test,
under valgrind, it is too huge.

a transaction that holds a lock on a clustered index record
also holds a lock on the secondary index record.