- remove totally wrong (syntax) entries from disabled.def
- remove entries belonging to deleted tests from disabled.def
- correct the comments (correct the bug mentioned) of entries in disabled.def
- remove never completed tests which were accidently pushed
The partitioning clause is only a very long single line, which is very
hard to interpret for a human. This patch breaks the partitioning
syntax into one line for the partitioning type, and one line per
partition/subpartition.
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
exists t1,t2,t3'
Bug #34245 Test ndb_binlog_multi fails for 'CREATE TABLE'
Bug #34246 Test rpl_ndb_transaction fails with 'Failed to create
'mysql/ndb_apply_status'
Tests cases didn't wait for cluster to come up due to a typo
in have_multi_ndb.inc.
Changed to use information_schema to check auto_increment
Ndb.cpp:
Bug #33534 Bad performance of INSERT's in auto_incremented tables: Saving highest seen value when setting auto_increment fields
ndb_auto_increment.result:
Regenerated result
Add a check if setting an auto_increment field will change it's next value before retrieving tuple_id_range lock. This avoids hitting locks when updating auto_increment values to a lower value than the current maximum. This is useful in loading a table with auto_increment where one loads the highest numbered pk's first and then proceeds backwards to the first. This can then be achieved with the same performance as a normal insert without auto_increment.
ndb_restore.result:
Updated result file
columns (default datatype value is assigned).
The mysql_update function has been modified to generate
an error when trying to set a NOT NULL field to NULL rather than a warning
in the set_field_to_null_with_conversions function.
Problem was that the mix of handlers was not consistent between
CREATE and ALTER
changed so that it works like:
- All partitions must use the same engine
AND it must be the same as the table.
- if one does NOT specify an engine on the table level
then one must either NOT specify any engine on any
partition/subpartition OR for ALL partitions/subpartitions
Note: that after a table have been created, the storage engine
is specified for all parts of the table (table/partition/subpartition)
and so when using alter, one does not need to specify it (unless one
wants to change the storage engine, then one have to specify it on the
table level)
When partition pruning resulted in an ordered index scan spanning only
one partition, any descending flag for the scan was wrongly discarded,
turning ORDER BY DESC into ORDER BY ASC, and similar problems.
Fixed by correctly passing descending flag in SCAN_TABREQ signal sent
to data nodes.
Now, every transaction (including autocommit transactions) starts with
a BEGIN and ends with a COMMIT/ROLLBACK in the binlog.
Added a test case, and updated lots of test case result files.
