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+.
REBUILD PARTITION under LOCK TABLE
Collapsed patch including updates from the reviews.
In case of failure in ALTER ... PARTITION under LOCK TABLE
the server could crash, due to it had modified the locked
table object, which was not reverted in case of failure,
resulting in a bad table definition used after the failed
command.
Solved by instead of altering the locked table object and
its partition_info struct, creating an internal temporary
intermediate table object used for altering,
just like the non partitioned mysql_alter_table.
So if an error occur before the alter operation is complete,
the original table is not modified at all.
But if the alter operation have succeeded so far that it
must be completed as whole,
the table is properly closed and reopened.
(The completion on failure is done by the ddl_log.)
mysql-test/suite/parts/inc/partition_fail.inc:
Added tests under LOCK TABLE
mysql-test/suite/parts/r/partition_debug_innodb.result:
Updated results
mysql-test/suite/parts/r/partition_debug_myisam.result:
Updated results
mysql-test/suite/parts/r/partition_special_innodb.result:
updated result
mysql-test/suite/parts/t/partition_special_innodb.test:
changing comment, since this patch also fixes this.
sql/sql_partition.cc:
Added TODO, to use DBUG_SUICIDE() instead of abort()
to avoid core-files on expected crashes.
Removed unused arguments to fast_end_partition.
Opening a intermediate table in prep_alter_part_table, instead of altering
(a possible locked) normally opened table.
That way we do not have to do anything more than close
the intermediate table on error,
leaving the ordinary table opened and locked.
Also making sure that the intermediate table are
closed/destroyed on failure. If no error occur
it is later destroyed in the end of fast_alter_partition_table.
Added ha_external_lock to make sure MyISAM flushed the index file
after copying the partitions.
This also leads to removal of the special close and removal from
the table cache for other instances of the table.
sql/sql_partition.h:
Changed the arguments for prep_alter_part_table and
fast_alter_partition_table to use an intermediate table
instead of altering a (possibly locked) normal table.
sql/sql_table.cc:
Using an intermediate table created in prep_alter_part_table
to be used in fast_alter_partition_table, also closing/destroying
it on failure.
Bug#57113: ha_partition::extra(ha_extra_function):
Assertion `m_extra_cache' failed
Fix for bug#55458 included DBUG_ASSERTS causing
debug builds of the server to crash on
another multi-table update.
Removed the asserts since they where wrong.
(updated after testing the patch in 5.5).
mysql-test/r/partition.result:
updated result
mysql-test/t/partition.test:
Added test for bug#57113
sql/ha_partition.cc:
Removed the assert for m_extra_cache when
::extra(HA_PREPARE_FOR_UPDATE) was called.
Trying to run perl fails, just like it does when perl is started but fails
Trap the case that perl was not found/could not be started, and skip test
Also force a restart of servers since test may already have done something
mtr now also appends path of current perl to PATH to aid mysqltest
This crash occured if the same debug trace file was closed twice,
leading to the same memory being free'd twice. This could occur
if the "debug" server system variable refered to the same trace
file in both global and session scope.
Example of an order of events that would lead to a crash:
1) Enable debug tracing to a trace file (global scope)
2) Enable debug tracing to the same trace file (session scope)
3) Reset debug settings (global scope)
4) Reset debug settings (session scope)
This caused a crash because the trace file was, by mistake, closed
in 3), leading to the same memory being free'd twice when the file
was closed again in 4).
Internally, the debug settings are stored in a stack, with session
settings (if any) on top and the global settings below. Each connection
has its own stack. When a set of settings is changed, it must be
determined if its debug trace file is to be closed. Before, this was done
by only checking below on the settings stack. So if the global settings
were changed, an existing debug trace file reference in session settings
would be missed. This caused the file to be closed even if it was in use,
leading to a crash later when it was closed again.
This patch fixes the problem by preventing the trace file from being shared
between global and session settings. If session debug settings are set without
specifying a new trace file, stderr is used for output. This is a change
in behaviour and should be reflected in the documentation.
Test case added to variables.test.
