Merge lp://staging/~hrvojem/percona-server/bug1059987-5.5 into lp://staging/percona-server/5.5

  - "additional writes (*fsync()* system calls) that are needed to
    store the additional information on the disk"
    =>
    "additional *fsync()* system calls on both binary and XtraDB REDO
    log when committing a transaction"

  - "a single *fsync()* to write the information to the storage for
    several transactions that are running concurrently"
    =>
    "a single *fsync()* calls to force data to the storage for multiple
    concurrently committing transactions"

  - s/multi-concurrent/write-concurrent/

  - "Pass corruptions of user tables as ``corrupt table`` instead of
    crashing itself"
    =>
    "Return error 1194 (ER_CRASHED_ON_USAGE) instead of crashing with an
    assertion failure"

  - "All file I/O for the datafile after detected as corrupt is
    disabled, except for the deletion."
    =>
    "Once corruption is detected, access to the corrupted tablespace is
    disabled. The only allowed operation on a corrupted tablespace is
    DROP TABLE. The only exception to this rule is when the option value
    is ``salvage`` (see below)."

  - "When the default value is used |InnoDB| will stop the server if it
    finds a checksum mismatch on the tables."
    =>
    "With the default value |XtraDB| will intentionally crash the
    server with an assertion failure as it would normally do when
    detecting corrupted data in a single-table tablespace."

  - "It still exists as :variable:`innodb_pass_corrupt_table`"
    =>
    "The option name was :variable:`innodb_pass_corrupt_table`"

  - s/If ``warn`` values/If the ``warn`` value/

  - "Value ``salvage`` can be used to dump a table which has a few pages
    corrupt, by skipping over them. This value is intended for Data
    Recovery rather than everyday use."
    =>
    "When the option value is ``salvage``, |XtraDB| allows read access
    to a corrupted tablespace, but ignores corrupted pages".

  - I think we can avoid that note about innodb_buffer_pool_populate's
    default value being sometimes displayed as ON or OFF. That remark
    applies to all boolean variables starting with "innodb_". Such as:

    - innodb_track_changed_pages
    - innodb_buffer_pool_shm_key (which is in fact incorrectly
      documented as Boolean, but the feature itself is deprecated, so
      we probably don't care)
    - innodb_stats_auto_update
    - innodb_use_sys_stats_table
    - etc., etc.

    There are multiple upstream issues here related to boolean
    variables inconsistencies here. The best thing we can do here is
    probably just document possible values for all XtraDB boolean
    variables as 0/1.

  - explanations for innodb_fast_checksum should make it clear that the
    feature has been marked deprecated in Percona Server 5.1/5.5 and
    will not be available in Percona Server 5.6, because the
    innodb_checksum_algorithm feature in MySQL 5.6 makes it redundant.

  - s/Only difference is the different default value/The only
    difference is the default value/

  - the MP also links to bug #996545
    "innodb_adaptive_flushing_method=estimate and innodb_io_capacity",
    but I don't see any relevant changes in the diff?

Fixed as suggested.

> - the MP also links to bug #996545
> "innodb_adaptive_flushing_method=estimate and innodb_io_capacity",
> but I don't see any relevant changes in the diff?
It's here:
152 - If the oldest modified age exceeds 1/4 of the maximum age capacity, |InnoDB| starts flushing blocks every second. The number of blocks flushed is determined by [number of modified blocks], [LSN progress speed] and [average age of all modified blocks]. So, this behavior is independent of the ``innodb_io_capacity`` variable.
153 + If the oldest modified age exceeds 1/4 of the maximum age capacity, |InnoDB| starts flushing blocks every second. The number of blocks flushed is determined by [number of modified blocks], [LSN progress speed] and [average age of all modified blocks].

Sorry, I overlooked that change about the 'estimate' flushing method. Looking at the bug report, I think we should just make it clear that the described behavior is independent of the innodb_io_capacity variable for the 1-second loop, but the variable still has an effect for the 10-second loop.

Approved, but please remove double "for" in "for for the 1-second loop".