extraneous file
Online/fast ALTER TABLE of a partitioned table may leave
temporary file in database directory.
Fixed by removing unnecessary call to
handler::ha_create_handler_files(), which was creating
partitioning definition file.
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.
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.
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.
Fixes:
Bug #18942: DROP DATABASE does not drop an orphan FOREIGN KEY constraint
Fix Bug#18942 by dropping all foreign key constraints at the end of
DROP DATABASE. Usually, by then, there are no foreign constraints
left because all of them are dropped when the relevant tables are
dropped. This code is to ensure that any orphaned FKs are wiped too.
Bug #29157: UPDATE, changed rows incorrect
Return HA_ERR_RECORD_IS_THE_SAME from ha_innobase::update_row() if no
columns were updated.
Bug #32440: InnoDB free space info does not appear in SHOW TABLE STATUS or I_S
Put information about the free space in a tablespace in
INFORMATION_SCHEMA.TABLES.DATA_FREE. This information was previously
available in INFORMATION_SCHEMA.TABLES.TABLE_COMMENT, but MySQL has
removed it from there recently.
The stored value is in kilobytes.
This can be considered as a permanent workaround to
http://bugs.mysql.com/32440. "Workaround" becasue that bug is about the
data missing from TABLE_COMMENT and this is actually not solved.
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)
Problem: when alter to partitioned table,
it does not see it as change of engine.
Solution: If alter includes partitioning, check if it is possible
to change engines (eg. is the table referenced by a FK)
Before the fix:
ha_partition objects had ha_partition::m_part_info==NULL and that caused
crash
After:
- The new ha_partition::clone() function makes the clones use parent's
m_part_info value.
- The parent ha_partition object remains responsible for deallocation of
m_part_info.
Before this fix, the command SHOW ENGINE <name> STATUS would:
- print a warning if the engine name is unknown,
- proceed and implement the same behavior as SHOW ENGINE ALL STATUS,
and list the status of all the storage engines registered.
In particular, this behavior caused confusion about the command :
SHOW ENGINE MUTEX STATUS, which as a side effect would print the status
of the innodb engine when that engine is registered.
Also, before this fix, every time an unknown engine name was substituted by
the default engine (which happen unless SQL_MODE NO_ENGINE_SUBSTITUTION is
set), a malformed warning was raised.
For example, the command ALTER TABLE T1 ENGINE = X would print :
Warnings:
Error 1286 Unknown table engine 'X'
With this fix:
SHOW ENGINE <name> STATUS|LOGS|MUTEX
always fails with an error when the engine <name> is unknown.
For other commands, warnings about unknown engines are raised as:
Warnings:
Warning 1286 Unknown table engine 'X'
In other words, engine substitution never affect the SHOW ENGINE command,
since this would lead to very confusing results.