GitLab

             SECONDARY INDEX IN INNODB

The patches for Bug#11751388 and Bug#11784056 enabled concurrent
reads while creating secondary indexes in InnoDB. However, they
introduced a regression. This regression occured if ALTER TABLE
failed after the index had been added, for example during the
lock upgrade needed to update .FRM. If this happened, InnoDB
and the server got out of sync with regards to which indexes
actually existed. Therefore the patch for Bug#11815600 again
disabled concurrent reads.

This patch re-enables concurrent reads. The original regression
is fixed by splitting the ADD INDEX operation into two parts.
First the new index is created but not made active. This is
done while concurrent reads are allowed. The second part of
the operation makes the index active (or reverts the change).
This is done after lock upgrade, which prevents the original
regression.

In order to implement this change, the patch changes the storage
API for in-place index creation. handler::add_index() is split
into two functions, handler_add_index() and
handler::final_add_index(). The former for creating indexes without
making them visible and the latter for commiting (i.e. making
visible) new indexes or reverting the changes.

Large parts of this patch were written by Marko Mäkelä.

Test case added to innodb_mysql_lock.test.

Update for previous patch according to reviewers comments.

Updated the constructors for ha_partitions to use the common
init_handler_variables functions

Added use of defines for size and offset to get better readability for the code that reads
and writes the .par file. Also refactored the get_from_handler_file function.

When executing row-ordered-retrieval index merge,
the handler was cloned, but it used the wrong
memory root, so instead of allocating memory
on the thread/query's mem_root, it used the table's
mem_root, resulting in non released memory in the
table object, and was not freed until the table was
closed.

Solution was to ensure that memory used during cloning
of a handler was allocated from the correct memory root.

This was implemented by fixing handler::clone() to also
take a name argument, so it can be used with partitioning.
And in ha_partition only allocate the ha_partition's ref, and
call the original ha_partition partitions clone() and set at cloned
partitions.

Fix of .bzrignore on Windows with VS 2010

           but the statement is written to binlog

TRUNCATE PARTITION was written to the binlog
even if it failed before calling any partition's
truncate function.

Solved by adding an argument to truncate_partition,
to flag if it should be written to the binlog or not.

It should be written to the binlog when a call to any
partitions truncate function is done.

mysql-test/r/partition_binlog.result:
  New result file
mysql-test/t/partition_binlog.test:
  New test file, including DROP PARTITION binlog test
sql/ha_partition.cc:
  Added argument to avoid binlogging failed truncate_partition that
  have not yet changed any data.
sql/ha_partition.h:
  Added argument to avoid excessive binlogging
sql/sql_partition_admin.cc:
  Avoid to binlog TRUNCATE PARTITION if it fails before
  any partition has tried to truncate.

Bug#54678: InnoDB, TRUNCATE, ALTER, I_S SELECT, crash or deadlock

- Incompatible change: truncate no longer resorts to a row by
row delete if the storage engine does not support the truncate
method. Consequently, the count of affected rows does not, in
any case, reflect the actual number of rows.

- Incompatible change: it is no longer possible to truncate a
table that participates as a parent in a foreign key constraint,
unless it is a self-referencing constraint (both parent and child
are in the same table). To work around this incompatible change
and still be able to truncate such tables, disable foreign checks
with SET foreign_key_checks=0 before truncate. Alternatively, if
foreign key checks are necessary, please use a DELETE statement
without a WHERE condition.

Problem description:

The problem was that for storage engines that do not support
truncate table via a external drop and recreate, such as InnoDB
which implements truncate via a internal drop and recreate, the
delete_all_rows method could be invoked with a shared metadata
lock, causing problems if the engine needed exclusive access
to some internal metadata. This problem originated with the
fact that there is no truncate specific handler method, which
ended up leading to a abuse of the delete_all_rows method that
is primarily used for delete operations without a condition.

Solution:

The solution is to introduce a truncate handler method that is
invoked when the engine does not support truncation via a table
drop and recreate. This method is invoked under a exclusive
metadata lock, so that there is only a single instance of the
table when the method is invoked.

Also, the method is not invoked and a error is thrown if
the table is a parent in a non-self-referencing foreign key
relationship. This was necessary to avoid inconsistency as
some integrity checks are bypassed. This is inline with the
fact that truncate is primarily a DDL operation that was
designed to quickly remove all data from a table.

mysql-test/suite/innodb/t/innodb-truncate.test:
  Add test cases for truncate and foreign key checks.
  Also test that InnoDB resets auto-increment on truncate.
mysql-test/suite/innodb/t/innodb.test:
  FK is not necessary, test is related to auto-increment.
  
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
mysql-test/suite/innodb/t/innodb_mysql.test:
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
  
  Use delete instead of truncate, test is used to check
  the interaction of FKs, triggers and delete.
mysql-test/suite/parts/inc/partition_check.inc:
  Fix typo.
mysql-test/suite/sys_vars/t/foreign_key_checks_func.test:
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
mysql-test/t/mdl_sync.test:
  Modify test case to reflect and ensure that truncate takes
  a exclusive metadata lock.
mysql-test/t/trigger-trans.test:
  Update error number, truncate is no longer invoked if
  table is parent in a FK relationship.
sql/ha_partition.cc:
  Reorganize the various truncate methods. delete_all_rows is now
  passed directly to the underlying engines, so as truncate. The
  code responsible for truncating individual partitions is moved
  to ha_partition::truncate_partition, which is invoked when a
  ALTER TABLE t1 TRUNCATE PARTITION p statement is executed.
  
  Since the partition truncate no longer can be invoked via
  delete, the bitmap operations are not necessary anymore. The
  explicit reset of the auto-increment value is also removed
  as the underlying engines are now responsible for reseting
  the value.
sql/handler.cc:
  Wire up the handler truncate method.
sql/handler.h:
  Introduce and document the truncate handler method. It assumes
  certain use cases of delete_all_rows.
  
  Add method to retrieve the list of foreign keys referencing a
  table. Method is used to avoid truncating tables that are
  parent in a foreign key relationship.
sql/share/errmsg-utf8.txt:
  Add error message for truncate and FK.
sql/sql_lex.h:
  Introduce a flag so that the partition engine can detect when
  a partition is being truncated. Used to give a special error.
sql/sql_parse.cc:
  Function mysql_truncate_table no longer exists.
sql/sql_partition_admin.cc:
  Implement the TRUNCATE PARTITION statement.
sql/sql_truncate.cc:
  Change the truncate table implementation to use the new truncate
  handler method and to not rely on row-by-row delete anymore.
  
  The truncate handler method is always invoked with a exclusive
  metadata lock. Also, it is no longer possible to truncate a
  table that is parent in some non-self-referencing foreign key.
storage/archive/ha_archive.cc:
  Rename method as the description indicates that in the future
  this could be a truncate operation.
storage/blackhole/ha_blackhole.cc:
  Implement truncate as no operation for the blackhole engine in
  order to remain compatible with older releases.
storage/federated/ha_federated.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required to support partition truncate as this
  form of truncate does not implement the drop and recreate
  protocol.
storage/heap/ha_heap.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required to support partition truncate as this
  form of truncate does not implement the drop and recreate
  protocol.
storage/ibmdb2i/ha_ibmdb2i.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required to support partition truncate as this
  form of truncate does not implement the drop and recreate
  protocol.
storage/innobase/handler/ha_innodb.cc:
  Rename delete_all_rows to truncate. InnoDB now does truncate
  under a exclusive metadata lock.
  
  Introduce and reorganize methods used to retrieve the list
  of foreign keys referenced by a or referencing a table.
storage/myisammrg/ha_myisammrg.cc:
  Introduce truncate method that invokes delete_all_rows.
  This is required in order to remain compatible with earlier
  releases where truncate would resort to a row-by-row delete.

LOAD DATA into partitioned MyISAM table

Problem was that both partitioning and myisam
used the same table_share->mutex for different protections
(auto inc and repair).

Solved by adding a specific mutex for the partitioning
auto_increment.

Also adding destroying the ha_data structure in
free_table_share (which is to be propagated
into 5.5).

This is a 5.1 ONLY patch, already fixed in 5.5+.

Updated according to reviewers comments.

Problem was that the handler call ::extra(HA_EXTRA_CACHE) was cached
but the ::extra(HA_EXTRA_PREPARE_FOR_UPDATE) was not.

Solution was to also cache the other call and forward it when moving
to a new partition to scan.

mysql-test/r/partition.result:
  test result
mysql-test/t/partition.test:
  New test from bug report.
sql/ha_partition.cc:
  cache the HA_EXTRA_PREPARE_FOR_UPDATE just like HA_EXTRA_CACHE.
sql/ha_partition.h:
  Added cache flag for HA_EXTRA_PREPARE_FOR_UPDATE

Remove code that has been disabled for a long time.

In bug-28430 HA_PRIMARY_KEY_REQUIRED_FOR_POSITION
was disabled in the partitioning engine in the first patch,
That bug was later fixed a second time, but that flag
was not removed.

No need to disable this flag, as it leads to bad
choise in row replication.

sql/ha_partition.h:
  Not disabling HA_PRIMARY_KEY_REQUIRED_FOR_POSITION flag.
  Updated comment (has nothing to do with hidden key.
sql/handler.h:
  Updated comments to about HA_PRIMARY_KEY_REQUIRED_FOR_POSITION.

The handler function for reading one row from a specific index
was not optimized in the partitioning handler since it
used the default implementation.

No test case since it is performance only, verified by hand.

sql/ha_partition.cc:
  Implemented a optimized version of index_read_idx_map
  for the case when find flag == HA_READ_KEY_EXACT,
  which is the common case.
sql/ha_partition.h:
  Declared ha_partition::index_read_idx_map

This patch:

- Moves all definitions from the mysql_priv.h file into
  header files for the component where the variable is
  defined
- Creates header files if the component lacks one
- Eliminates all include directives from mysql_priv.h
- Eliminates all circular include cycles
- Rename time.cc to sql_time.cc
- Rename mysql_priv.h to sql_priv.h

into partitioned MyISAM table

Problem was that the ha_data structure was introduced in 5.1
and only used for partitioning first, but with the intention
of be of use for others engines as well, and when used by other
engines it would clash if it also was partitioned.

Solution is to move the partitioning specific data to a separate
structure, with its own mutex (which is used for auto_increment).

Also did rename PARTITION_INFO to PARTITION_STATS since there
already exist a class named partition_info, also cleaned up
some related variables.

mysql-test/r/partition_binlog_stmt.result:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  New result file
mysql-test/t/partition_binlog_stmt.test:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  New result file
sql/ha_ndbcluster.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Rename of PARTITION_INFO to PARTITION_STATS to better
  match the use (and there is also a class named
  partition_info...)
sql/ha_ndbcluster.h:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Rename of PARTITION_INFO to PARTITION_STATS to better
  match the use (and there is also a class named
  partition_info...)
sql/ha_partition.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed the partitioning engines use of ha_data in
  TABLE_SHARE and added ha_part_data instead, since
  they collide if used in the same time.
  
  Rename of PARTITION_INFO to PARTITION_STATS to better
  match the use (and there is also a class named
  partition_info...)
  
  Removed some dead code.
sql/ha_partition.h:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed some dead code.
  
  Rename of PARTITION_INFO to PARTITION_STATS to better
  match the use (and there is also a class named
  partition_info...)
  
  Removed the partitioning engines use of ha_data in
  TABLE_SHARE and added ha_part_data instead, since
  they collide if used in the same time.
sql/handler.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Rename of PARTITION_INFO to PARTITION_STATS to better
  match the use (and there is also a class named
  partition_info...)
sql/handler.h:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Rename of PARTITION_INFO to PARTITION_STATS to better
  match the use (and there is also a class named
  partition_info...)
sql/mysql_priv.h:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed the partitioning engines use of ha_data in
  TABLE_SHARE and added ha_part_data instead, since
  they collide if used in the same time.
  
  Added key_PARTITION_LOCK_auto_inc for instrumentation.
sql/mysqld.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed the partitioning engines use of ha_data in
  TABLE_SHARE and added ha_part_data instead, since
  they collide if used in the same time.
  
  Added key_PARTITION_LOCK_auto_inc for instrumentation.
sql/partition_info.h:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed part_state* since it was not in use.
sql/sql_partition.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed part_state* since it was not in use.
sql/sql_partition.h:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Cleaned up old commented out code.
  
  Removed part_state* since it was not in use.
sql/sql_show.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Rename of PARTITION_INFO to PARTITION_STATS to better
  match the use (and there is also a class named
  partition_info...)
  
  Renamed partition_info to partition_info_str, since
  partition_info is a name of a class.
sql/sql_table.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Renamed partition_info to partition_info_str, since
  partition_info is a name of a class.
sql/table.cc:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed the partitioning engines use of ha_data in
  TABLE_SHARE and added ha_part_data instead, since
  they collide if used in the same time.
  
  Renamed partition_info to partition_info_str, since
  partition_info is a name of a class.
  
  removed part_state* since it was not in use.
sql/table.h:
  Bug#51851: Server with SBR locks mutex twice on LOAD DATA
  into partitioned MyISAM table
  
  Removed the partitioning engines use of ha_data in
  TABLE_SHARE and added ha_part_data instead, since
  they collide if used in the same time.
  
  Renamed partition_info to partition_info_str, since
  partition_info is a name of a class.
  
  removed part_state* since it was not in use.

Part IV: sql instrumentation

-------------------------------------------------------------------
revno: 2630.6.6
committer: Konstantin Osipov <konstantin@mysql.com>
branch nick: mysql-6.0-3726
timestamp: Tue 2008-05-27 16:15:44 +0400
message:
Implement code review fixes for WL#3726 "DDL locking for all
metadata objects": cleanup the code from share->mutex
acquisitions, which are now obsolete.

sql/ha_partition.cc:
  Rename share->mutex to share->LOCK_ha_data. The mutex never
  protected the entire share. The right way to protect a share
  is to acquire an MDL lock.
sql/ha_partition.h:
  Rename share->mutex to share->LOCK_ha_data.
sql/sql_base.cc:
  Remove LOCK_table_share. Do not acquire share->mutex when
  deleting a table share or incrementing its ref_count.
  All these operations are and must continue to be protected by LOCK_open
  and respective MDL locks.
sql/sql_view.cc:
  Remove acquisition of share->mutex when incrementing share->ref_count.
sql/table.cc:
  Simplify release_table_shar() by removing dead code related
  to share->mutex from it.
sql/table.h:
  Rename TABLE_SHARE::mutex to TABLE_SHARE::LOCK_ha_data
  to better reflect its purpose.
storage/myisam/ha_myisam.cc:
  Rename share->mutex to share->LOCK_ha_data.

Problem was that ha_partition::records_in_range called
records_in_range for all non pruned partitions, even if
an estimate should be given.

Solution is to only use 1/3 of the partitions (up to 10) for
records_in_range and estimate the total from this subset.
(And continue until a non zero return value from the called
partitions records_in_range is given, since 0 means no rows
will match.)

sql/ha_partition.cc:
  Bug#48846: Too much time spent in ha_partition::records_in_range if not able to prune
  
  estimate_rows_upper_bound and records_in_range are very similar
  (the only difference is the function and its parameters to use)
  so I created a common function for this.
  
  Since these calls from the optimizer are only estimates, it is
  not neccesary to call them for every partition, it can use
  a much smaller subset of the used partitions instead,
  which improves performance for selects.
sql/ha_partition.h:
  Bug#48846: Too much time spent in ha_partition::records_in_range if not able to prune
  
  Added two private functions to help some
  optimizer calls.

                get_table_share, drop_open_table
            
In the partition handler code, LOCK_open and share->LOCK_ha_data
are acquired in the wrong order in certain cases.  When doing a
multi-row INSERT (i.e a INSERT..SELECT) in a table with auto-
increment column(s). the increments must be in a monotonically
continuous increasing sequence (i.e it can't have "holes"). To
achieve this, a lock is held for the duration of the operation.
share->LOCK_ha_data was used for this purpose.
            
Whenever there was a need to open a view _during_ the operation
(views are not currently pre-opened the way tables are), and
LOCK_open was grabbed, a deadlock could occur.  share->LOCK_ha_data
is other places used _while_ holding LOCK_open.
            
A new mutex was introduced in the HA_DATA_PARTITION structure,
for exclusive use of the autoincrement data fields, so we don't
need to overload the use of LOCK_ha_data here.
            
A module test case has not been supplied, since the problem occurs
as a result of a race condition, and testing for this condition 
is thus not deterministic.   Testing for it could be done by
setting up a test case as described in the bug report.

Changed all no_ to num_ to avoid strange names like no_list_values which is not expected to be number of list values, rather a boolea indicating no list values

            
Adding header include file guards to files that are missing such.

with gcc 4.3.2

Cleaning up warnings not present in 5.0.

 "insert into.. select * from"

When inserting into a partitioned table using 'insert into
<target> select * from <src>', read_buffer_size bytes of memory
are allocated for each partition in the target table.

This resulted in large memory consumption when the number of
partitions are high.

This patch introduces a new method which tries to estimate the
buffer size required for each partition and limits the maximum
buffer size used to maximum of 10 * read_buffer_size, 
11 * read_buffer_size in case of monotonic partition functions.

sql/ha_partition.cc:
  Introduced a method ha_partition::estimate_read_buffer_size
  to estimate buffer size required for each partition. 
  Method ha_partition::start_part_bulk_insert updated
  to update the read_buffer_size before calling bulk upload
  in storage engines.
  Added thd in ha_partition::start_part_bulk_insert method signature.
sql/ha_partition.h:
  Introduced a method ha_partition::estimate_read_buffer_size.
  Added thd in ha_partition::start_part_bulk_insert method signature.

WL#3352, Introducing Column list partitioning, makes it possible to partition on most data types, makes it possible to prune on multi-field partitioning

WL#4571, Enable Key cache defined for a partition to enable more scalability on partitioned MyISAM tables among other things

(Backport)

Problem is that when insert (ha_start_bulk_insert) in i partitioned table,
it will call ha_start_bulk_insert for every partition, used or not.

Solution is to delay the call to the partitions ha_start_bulk_insert until
the first row is to be inserted into that partition


sql/ha_partition.cc:
  Bug#35845: unneccesary call to ha_start_bulk_insert for not used partitions
  
  Using a bitmap for keeping record of which partitions for which
  ha_start_bulk_insert has been called, and check against that if one
  should call it before continue with the insert/update, or if it has already
  been called.
  
  This way it will only call ha_start_bulk_insert for the used partitions.
  There is also a little prediction on how many rows that will be inserted into
  the current partition, it will guess on equal distribution of the records
  across all partitions, accept for the first used partition, which will guess
  at 50% of the given estimate, if it is a monotonic partitioning function.
sql/ha_partition.h:
  Bug#35845: unneccesary call to ha_start_bulk_insert for not used partitions
  
  Added help variables and function for delaying ha_bulk_insert until it has
  to be called.
  
  Fixed a comment.

Inserting a negative value in the autoincrement column of a
partitioned innodb table was causing the value of the auto
increment counter to wrap around into a very large positive
value. The consequences are the same as if a very large positive
value was inserted into a column, e.g. reduced autoincrement
range, failure to read autoincrement counter.

The current patch ensures that before calculating the next
auto increment value, the current value is within the positive
maximum allowed limit.

mysql-test/suite/parts/inc/partition_auto_increment.inc:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Adds tests for performing insert,update and delete on a partition
  table with negative auto_increment values.
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the innodb engine.
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the memory engine.
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the myisam engine.
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Result file for the ndb engine.
mysql-test/suite/parts/t/partition_auto_increment_archive.test:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Adds a variable that allows the Archive engine to skip tests
  that involve insertion of negative auto increment values.
mysql-test/suite/parts/t/partition_auto_increment_blackhole.test:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Adds a variable that allows the Blackhole engine to skip tests
  that involve insertion of negative auto increment values.
sql/ha_partition.cc:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Ensures that the current value is lesser than the upper limit
  for the type of the field before setting the next auto increment
  value to be calculated.
sql/ha_partition.h:
  Bug#45823 Assertion failure in file row/row0mysql.c line 1386
  
  Modifies the set_auto_increment_if_higher function, to take
  into account negative auto increment values when doing a
  comparison.

Addition of hander function was_semi_consistent_read

mysql-test/r/partition_innodb_semi_consistent.result:
  post push fix for bug#40595
  Addition of hander function was_semi_consistent_read
  
  Added test result
mysql-test/t/partition_innodb_semi_consistent-master.opt:
  post push fix for bug#40595
  Addition of hander function was_semi_consistent_read
  
  Added test opt file
mysql-test/t/partition_innodb_semi_consistent.test:
  post push fix for bug#40595
  Addition of hander function was_semi_consistent_read
  
  Added test case
sql/ha_partition.cc:
  post push fix for bug#40595
  Addition of hander function was_semi_consistent_read
  
  The lack of was_semi_consistent_read opened a regression
  for bug-31310 when useing a partitioned InnoDB table

since Oct 1st

on tables with partitions

Problem was that the handler function try_semi_consistent_read
was not propagated to the innodb handler.

Solution was to implement that function in the partitioning
handler.

mysql-test/r/partition_innodb.result:
  Bug#40595: Non-matching rows not released with READ-COMMITTED
  on tables with partitions
  
  Updated test result.
mysql-test/t/partition_innodb.test:
  Bug#40595: Non-matching rows not released with READ-COMMITTED
  on tables with partitions
  
  Added test case for bug#40595.
  
  Note: the replace_regex is taking long time. I have not found
  any better regex (it takes time using 'sed' too).
sql/ha_partition.cc:
  Bug#40595: Non-matching rows not released with READ-COMMITTED
  on tables with partitions
  
  Added function to the partitioning handler for handling
  semi consistent reads (unlock_row was already implemented,
  and this is needed for unlock_row to work properly in innodb).
  It uses pruning for optimizing the call.
sql/ha_partition.h:
  Bug#40595: Non-matching rows not released with READ-COMMITTED
  on tables with partitions
  
  Added function to the partitioning handler for handling
  semi consistent reads (unlock_row was already implemented,
  and this is needed for unlock_row to work properly in innodb).

Problem was that partitioning cached the table flags.
These flags could change due to TRANSACTION LEVEL changes.
Solution was to remove the cache and always return the table flags
from the first partition (if the handler was initialized).

mysql-test/r/partition_innodb_stmt.result:
  Bug#39084: Getting intermittent errors with statement-based binary logging
  
  New test result file.
mysql-test/t/partition_innodb_stmt.test:
  Bug#39084: Getting intermittent errors with statement-based binary logging
  
  New test file.
sql/ha_partition.cc:
  Bug#39084: Getting intermittent errors with statement-based binary logging
  
  Removed m_table_flags, and added m_handler_status.
  Added checks that all partitions have the same
  table flags.
  Moved some variable initializations.
  Updated some comments.
  Fixed typo initialise -> initialize
  Changed HA_EXTTA_NO_READCHECK to do nothing, since it
  is only used in ha_open, which is called for every
  partition in ::open anyway.
sql/ha_partition.h:
  Bug#39084: Getting intermittent errors with statement-based binary logging
  
  Removed m_table_flags, and added m_handler_status.
  Always return the first partitions table flags, instead of using
  cached table flags.
  Added define of enabled/disabled partitioning table flags
  Fixed type initialise -> initialize
  Updated some comments.
sql/handler.cc:
  Bug#39084: Getting intermittent errors with statement-based binary logging
  
  Fixed type initialise -> initialize.
sql/handler.h:
  Bug#39084: Getting intermittent errors with statement-based binary logging
  
  Added comment to understand where the cached value is set.

breaks auto increment

The auto_increment value was not initialized if
the first statement after opening a table was
an 'UPDATE'.

solution was to check initialize if it was not,
before trying to increase it in update.

mysql-test/suite/parts/inc/partition_auto_increment.inc:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Added tests for verifying the bug and show some more
  auto_increment flaws
mysql-test/suite/parts/r/partition_auto_increment_archive.result:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Updated test results, due to added tests
mysql-test/suite/parts/r/partition_auto_increment_blackhole.result:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Updated test results, due to added tests
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Updated test results, due to added tests
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Updated test results, due to added tests
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Updated test results, due to added tests
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Updated test results, due to added tests
sql/ha_partition.cc:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  make sure that the auto_increment value is initialized
  before updating it.
  
  (missed initializing in mysql_update_row).
sql/ha_partition.h:
  Bug#40176: update as first partitioning statement
  breaks auto increment
  
  Assert that it is initialized, before updating
  the auto_increment value

on non-partitioned table

Problem was that partitioning specific commands was accepted
for non partitioned tables and treated like
ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE, after bug-20129 was fixed,
which changed the code path from mysql_alter_table to
mysql_admin_table.

Solution was to check if the table was partitioned before
trying to execute the admin command

mysql-test/r/partition_mgm_err.result:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Updated test result
mysql-test/t/partition_mgm_err.test:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Updated test case
sql/ha_partition.cc:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Simplified the code by using ALTER_ADMIN_PARTITION for all
  commands that go through mysql_admin_tables and is set
  for partitioning specific commands that.
sql/ha_partition.h:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Simplified the code by using ALTER_ADMIN_PARTITION for all
  commands that go through mysql_admin_tables and is set
  for partitioning specific commands that.
sql/sql_lex.h:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Simplified the code by using ALTER_ADMIN_PARTITION for all
  commands that go through mysql_admin_tables and is set
  for partitioning specific commands that.
  
  Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
  added ALTER_ADMIN_PARTITION instead.
sql/sql_partition.cc:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Simplified the code by using ALTER_ADMIN_PARTITION for all
  commands that go through mysql_admin_tables and is set
  for partitioning specific commands that.
  
  Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
  added ALTER_ADMIN_PARTITION instead.
sql/sql_table.cc:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Give error and return if trying partitioning admin command
  on non partitioned table.
  
  Simplified the code by using ALTER_ADMIN_PARTITION for all
  commands that go through mysql_admin_tables and is set
  for partitioning specific commands that.
  
  Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
  added ALTER_ADMIN_PARTITION instead.
sql/sql_yacc.yy:
  Bug#39434: ALTER TABLE CHECK/OPTIMIZE/ANALYZE PARTITION work
  on non-partitioned table
  
  Simplified the code by using ALTER_ADMIN_PARTITION for all
  commands that go through mysql_admin_tables and is set
  for partitioning specific commands that.
  
  Removed ALTER_ANALYZE/CHECK/OPTIMIZE/REPAIR_PARTITION and
  added ALTER_ADMIN_PARTITION instead.

index column

There was actually two problems
1) when clustered pk, order by non pk index should also
compare with pk as last resort to differ keys from each
other
2) bug in the index search handling in ha_partition (was
found when extending the test case

Solution to 1 was to include the pk in key compare if
clustered pk and search on other index.

Solution for 2 was to remove the optimization from
ordered scan to unordered scan if clustered pk.

mysql-test/r/partition_innodb.result:
  Bug#37721: ORDER BY when WHERE contains non-partitioned
  index column
  
  updated test result.
mysql-test/t/partition_innodb.test:
  Bug#37721: ORDER BY when WHERE contains non-partitioned
  index column
  
  Added test case for bug verification.
sql/ha_partition.cc:
  Bug#37721: ORDER BY when WHERE contains non-partitioned
  index column
  
  using m_curr_key_info with both given index and PK
  if clustered PK.
  Also including PK in read_set.
  Added debug prints for easier verification.
sql/ha_partition.h:
  Bug#37721: ORDER BY when WHERE contains non-partitioned
  index column
  
  Changed m_curr_key_info to a null terminated array
  with max 2 keys and a terminating null.
  For use with key_rec_cmp with both given index and PK.
sql/key.cc:
  Bug#37721: ORDER BY when WHERE contains non-partitioned
  index column
  
  added handling of a null terminated array of keys for
  use in compare.

InnoDB Plugin locks table

The fast/on-line add/drop index handler calls was not implemented
whithin the partitioning.

This implements it in the partitioning handler.

Since this is only used by the not included InnoDB plugin, there
is no test case. (Have tested it manually with the plugin, and
it does not allow unique indexes not including partitioning
function, or removal of pk, which in innodb generates a new pk,
which is not in the partitioning function.)

NOTE: This introduces a new handler method, and because of that
changes the storage engine api. (One cannot use a handlerton to
see the capabilities of a table's handler if it is partitioned.
So I added a wrapper function in the handler that defaults to
the handlerton function, which the partitioning handler overrides.

sql/ha_partition.cc:
  Bug#37453: Dropping/creating index on partitioned table with
  InnoDB Plugin locks table
  
  Added support for fast/on-line add/drop index.
  Implemented alter_table_flags as bit-or of the partitioned
  hton and the first partitions alter_table_flags.
  
  It is only to forward the calls for the other functions:
  check_if_incompatible_data
  add_index
  prepare_drop_index
  final_drop_index
  
  to all parts handler
sql/ha_partition.h:
  Bug#37453: Dropping/creating index on partitioned table with
  InnoDB Plugin locks table
  
  Added support for fast/on-line add/drop index.
sql/handler.h:
  Bug#37453: Dropping/creating index on partitioned table with
  InnoDB Plugin locks table
  
  Added the function on handler level, defaulting to use
  the handlerton function, but a handler can override it.
  Needed for partitioned tables.
  
  NOTE: Change of storage engine api.
sql/sql_partition.cc:
  Bug#37453: Dropping/creating index on partitioned table with
  InnoDB Plugin locks table
  
  Using the new handler function, instead of the handlerton
  function. This works better with the partitioning handler.
sql/sql_table.cc:
  Bug#37453: Dropping/creating index on partitioned table with
  InnoDB Plugin locks table
  
  Using the new handler function, instead of the handlerton
  function. This works better with the partitioning handler.
  Also using new process info for 'manage keys' (kind of fix
  for bug-37550).

and
Bug#33555: Group By Query does not correctly aggregate partitions

Backport of bug-33257 which is the same bug.

read_range_*() calls was not passed to the partition handlers,
but was translated to index_read/next family calls.
Resulting in duplicates rows and wrong aggregations.

mysql-test/r/partition_range.result:
  Bug#30573: Ordered range scan over partitioned tables returns some rows twice
  
  Updated result file
mysql-test/t/partition_range.test:
  Bug#30573: Ordered range scan over partitioned tables returns some rows twice
  
  Re-enabled the test
sql/ha_partition.cc:
  Bug#30573: Ordered range scan over partitioned tables returns some rows twice
  
  backport of bug-33257, correct handling of read_range_* calls,
  without converting them to index_read/next calls
sql/ha_partition.h:
  Bug#30573: Ordered range scan over partitioned tables returns some rows twice
  
  backport of bug-33257, correct handling of read_range_* calls,
  without converting them to index_read/next calls

Problem was a mutex added in bug n 27405 for solving a problem
with auto_increment in partitioned innodb tables.
(in ha_partition::write_row over partitions file->ha_write_row)

Solution is to use the patch for bug#33479, which refines the
usage of mutexes for auto_increment.

Backport of bug-33479 from 6.0:

Bug-33479: auto_increment failures in partitioning

Several problems with auto_increment in partitioning
(with MyISAM, InnoDB. Locking issues, not handling
multi-row INSERTs properly etc.)

Changed the auto_increment handling for partitioning:
Added a ha_data variable in table_share for storage engine specific data
such as auto_increment value handling in partitioning, also see WL 4305
and using the ha_data->mutex to lock around read + update.

The idea is this:
Store the table's reserved auto_increment value in
the TABLE_SHARE and use a mutex to, lock it for reading and updating it
and unlocking it, in one block. Only accessing all partitions
when it is not initialized.
Also allow reservations of ranges, and if no one has done a reservation
afterwards, lower the reservation to what was actually used after
the statement is done (via release_auto_increment from WL 3146).
The lock is kept from the first reservation if it is statement based
replication and a multi-row INSERT statement where the number of
candidate rows to insert is not known in advance (like INSERT SELECT,
LOAD DATA, unlike INSERT VALUES (row1), (row2),,(rowN)).

This should also lead to better concurrancy (no need to have a mutex
protection around write_row in all cases)
and work with any local storage engine.

mysql-test/suite/parts/inc/partition_auto_increment.inc:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  Test source file for testing auto_increment
mysql-test/suite/parts/r/partition_auto_increment_archive.result:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  result file for testing auto_increment
mysql-test/suite/parts/r/partition_auto_increment_blackhole.result:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  result file for testing auto_increment
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  result file for testing auto_increment
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  result file for testing auto_increment
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  result file for testing auto_increment
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  result file for testing auto_increment
mysql-test/suite/parts/t/partition_auto_increment_archive.test:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  test file for testing auto_increment
mysql-test/suite/parts/t/partition_auto_increment_blackhole.test:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  test file for testing auto_increment
mysql-test/suite/parts/t/partition_auto_increment_innodb.test:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  test file for testing auto_increment
mysql-test/suite/parts/t/partition_auto_increment_memory.test:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  test file for testing auto_increment
mysql-test/suite/parts/t/partition_auto_increment_myisam.test:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  test file for testing auto_increment
mysql-test/suite/parts/t/partition_auto_increment_ndb.test:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  test file for testing auto_increment
sql/ha_partition.cc:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: Failures using auto_increment and partitioning
  
  Changed ha_partition::get_auto_increment from file->get_auto_increment
  to file->info(HA_AUTO_STATUS), since it is works better with InnoDB
  (InnoDB can have issues with partitioning and auto_increment,
  where get_auto_increment sometimes can return a non updated value.)
  
  Using the new table_share->ha_data for keeping the auto_increment
  value, shared by all instances of the same table.
  It is read+updated when holding a auto_increment specific mutex.
  Also added release_auto_increment to decrease gaps if possible.
  And a lock for multi-row INSERT statements where the number of candidate
  rows to insert is not known in advance (like INSERT SELECT, LOAD DATA;
  Unlike INSERT INTO (row1),(row2),,(rowN)).
  Fixed a small bug, copied++ to (*copied)++ and the same for deleted.
  Changed from current_thd, to ha_thd()
sql/ha_partition.h:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: Failures using auto_increment and partitioning
  
  Added a new struct HA_DATA_PARTITION to be used in table_share->ha_data
  Added a private function to set auto_increment values if needed
  Removed the restore_auto_increment (the hander version is better)
  Added lock/unlock functions for auto_increment handling.
  Changed copied/deleted to const.
sql/handler.h:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: auto_increment failures in partitioning
  
  Added const for changed_partitions
  Added comments about SQLCOM_TRUNCATE for delete_all_rows
sql/table.h:
  Bug#38804: Query deadlock causes all tables to be inaccessible.
  Backporting from 6.0 of:
  Bug-33479: Failures using auto_increment and partitioning
  
  Added a variable in table_share: ha_data for storage of storage engine
  specific data (such as auto_increment handling in partitioning).

partition is corrupt

The main problem was that ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR
PARTITION took another code path (over mysql_alter_table instead of
mysql_admin_table) which differs in two ways:
1) alter table opens the tables in a different way than admin tables do
   resulting in returning with error before it tried the command
2) alter table does not start to send any diagnostic rows to the client
   which the lower admin functions continue to use -> resulting in
   assertion crash

The fix:
Remapped ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION to use
the same code path as ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE t.
Adding check in mysql_admin_table to setup the partition list for
which partitions that should be used.


Partitioned tables will still not work with
REPAIR TABLE/PARTITION USE_FRM, since that requires moving partitions
to tables, REPAIR TABLE t USE_FRM, and check that the data still
fulfills the partitioning function and then move the table back to
being a partition.

NOTE: I have removed the following functions from the handler
interface:
analyze_partitions, check_partitions, optimize_partitions,
repair_partitions
Since they are not longer needed.
THIS ALTERS THE STORAGE ENGINE API

mysql-test/r/handler_innodb.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added a note result row.
mysql-test/r/innodb.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added a note result row.
mysql-test/r/innodb_mysql.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added a note result row.
mysql-test/r/partition.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
  tables.
mysql-test/r/trigger-trans.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added a note result row.
mysql-test/suite/ndb/r/ndb_partition_key.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
  tables.
mysql-test/suite/ndb/t/ndb_partition_key.test:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
  tables.
mysql-test/suite/parts/inc/partition_alter4.inc:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
  tables.
mysql-test/suite/parts/r/partition_alter4_innodb.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
  tables.
mysql-test/suite/parts/r/partition_alter4_myisam.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
  tables.
mysql-test/suite/rpl/r/rpl_failed_optimize.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added a note result row.
mysql-test/suite/rpl/r/rpl_innodb_mixed_dml.result:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added a note result row.
mysql-test/t/partition.test:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Updated after fixing ANALYZE/CHECK/OPTIMIZE/REPAIR partitioned
  tables.
sql/ha_partition.cc:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added a function for returning admin commands result rows
  Updated handle_opt_partitions to handle admin commands result rows,
  and some error filtering (as mysql_admin_table do).
  
  Removed the functions analyze/check/optimize/repair_partitions
  since they have no longer any use.
sql/ha_partition.h:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Removed analyze/check/optimize/repair_partitions since they
  are no longer are needed.
sql/handler.cc:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Removed analyze/check/optimize/repair_partitions since they
  are no longer are needed.
sql/handler.h:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Removed analyze/check/optimize/repair_partitions since they
  are no longer are needed.
sql/mysql_priv.h:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added set_part_state for reuse of code in mysql_admin_table.
  (Originally fond in sql/sql_partition.cc:prep_alter_part_table)
sql/protocol.cc:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added one assert and a debug print.
sql/sql_partition.cc:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Refactored code for setting up partition state, set_part_state,
  now used in both prep_alter_part_table and
  sql_table.cc:mysql_admin_table.
  Removed code for handling ANALYZE/CHECK/OPTIMIZE/REPAIR partitions,
  since it is now handled by mysql_admin_table.
sql/sql_table.cc:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Added functionality in mysql_admin_table to work with partitioned
  tables.
  Fixed a possible assertion bug for HA_ADMIN_TRY_ALTER
  (If analyze would output a row, it fails since the row was already
  started).
sql/sql_yacc.yy:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Remapped ALTER TABLE t ANALYZE/CHECK/OPTIMIZE/REPAIR PARTITION
  to use the same code path as ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE
  instead of taking the ALTER TABLE path.
  Added reset of alter_info for ANALYZE/CHECK/OPTIMIZE/REPAIR TABLE
  since it is now used by partitioned tables.
storage/myisam/mi_check.c:
  Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
  partition is corrupt
  
  Changed warning message from "Found X parts  Should be: Y parts"
  to "Found X key parts. Should be Y", since it could be confusing
  with partitioned tables.

problem was that ha_partition::records was not implemented, thus
using the default handler::records, which is not correct if the engine
does not support HA_STATS_RECORDS_IS_EXACT.
Solution was to implement ha_partition::records as a wrapper around
the underlying partitions records.

The rows column in explain partitions will now include the total
number of records in the partitioned table.

(recommit after removing out-commented code)

Problem was that auto_repair, is_crashed and check_and_repair was not
implemented in ha_partition.

Solution, implemented them as loop over all partitions for is_crashed and
check_and_repair, and using the first partition for auto_repair.

(Recommit after fixing review comments)

mysql-test/lib/mtr_report.pl:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  Added filter for crashed tables, when testing auto repair
mysql-test/std_data/corrupt_t1#P#p1.MYI:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  Corrupt MYI file for testing auto repair
mysql-test/std_data/corrupt_t1.MYI:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  Corrupt MYI file for testing auto repair
mysql-test/suite/parts/r/partition_repair_myisam.result:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  Result file for testing auto repair of crashed myisam partitions
mysql-test/suite/parts/t/partition_repair_myisam-master.opt:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  opt file for testing auto repair of crashed myisam partitions
mysql-test/suite/parts/t/partition_repair_myisam.test:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  Test file for testing auto repair of crashed myisam partitions
sql/ha_partition.cc:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  Added auto_repair as returning the first partitions auto_repair
  Added is_crashed and check_and_repair as loop over all partitions
sql/ha_partition.h:
  Bug#35161: --myisam-recover does not work for partitioned MyISAM tables
  
  Activating check_and_repair, auto_repair and is_crashed