order by
Problem was that the first index read was unordered,
and the next was ordered, resulting in use of
uninitialized data.
Solution was to use the correct variable to see if
the 'next' call should be ordered or not.
mysql-test/r/partition.result:
Bug#40494: MYSQL server crashes on range access with
partitioning and order by
Added test case for the bug.
mysql-test/t/partition.test:
Bug#40494: MYSQL server crashes on range access with
partitioning and order by
Added test case for the bug.
sql/ha_partition.cc:
Bug#40494: MYSQL server crashes on range access with
partitioning and order by
Used the wrong variable to decide to continue with
ordered or unordered scan.
order by
Problem was that the first index read was unordered,
and the next was ordered, resulting in use of
uninitialized data.
Solution was to use the correct variable to see if
the 'next' call should be ordered or not.
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.
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).
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
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.
- The problem was that we didn't inform the handler that we are going to close tables that are locked and may have (at least in Maria) be part of an active transaction.
Fix for Bug#39227 Maria: crash with ALTER TABLE PARTITION
Fix for Bug #39987 main.partition_not_windows fails under debug build
Fixed some compiler errors & warnings found by pushbuild
include/my_base.h:
Added HA_EXTRA_PREPARE_FOR_FORCED_CLOSE for signaling the handler that the file will be forced closed
include/my_global.h:
Removed 'register' from 'swap_variables' as this gives a warnings when the variables are structs. Compilers should also now be smart enough to figure out this themselves
mysql-test/r/subselect_debug.result:
Reset value of the debug variable; Without setting this the subselect_innodb test will fail when run after this one
mysql-test/suite/maria/r/maria.result:
Merged test with myisam.test
Added tests for new fixed bugs
mysql-test/suite/maria/t/maria.test:
Merged test with myisam.test
Added tests for new fixed bugs
mysql-test/t/subselect_debug.test:
Reset value of the debug variable; Without setting this the subselect_innodb test will fail when run after this one
mysys/my_uuid.c:
Fixed compiler error on windows
sql/ha_partition.cc:
Added support for the new extra flag: HA_EXTRA_PREPARE_FOR_FORCED_CLOSE (Bug #39226)
Ensure that we call extra() for HA_EXTRA_PREPARE_FOR_DROP (Bug#39227)
sql/mysqld.cc:
Fix for Bug #39987 main.partition_not_windows fails under debug build
The problem was that when compiling for purify/valgrind realpath() is not used, which causes test_if_data_home_dir to fail when it shouldn't
sql/sql_base.cc:
Call HA_EXTRA_PREPARE_FOR_FORCED_CLOSE for tables that are locked but we are going to force close without doing a commit
sql/sql_parse.cc:
More DBUG_PRINT. Fixed comments
storage/maria/ma_extra.c:
If HA_EXTRA_PREPARE_FOR_FORCED_CLOSE is called and the table is part of a transaction, remove the table from beeing part of a transaction.
This is safe as this is only used as part of flush tables or when the table is not part of a transaction
storage/myisam/mi_open.c:
Indentation fix
unittest/mysys/waiting_threads-t.c:
Remove not needed 'volatile' to get rid of compiler warnings on windows
Fixed also some failing tests after merge. The files that was touched outside of the merge has a more explicit comment
include/my_global.h:
Remove 'register' from 'swap_variables' as this gives a warnings when the variables are structs. Compilers should also now be smart enough to figure out this themselves
mysql-test/t/subselect_debug.test:
Reset value of the debug variable; Without setting this the subselect_innodb test will fail when run after this one
sql/mysqld.cc:
Fix for Bug #39987 main.partition_not_windows fails under debug build
The problem was that when compiling for purify/valgrind realpath() is not used, which causes test_if_data_home_dir to fail when it shouldn't
unittest/mysys/waiting_threads-t.c:
Remove not needed 'volatile' to get rid of compiler warnings on windows
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.
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
The problem was that we didn't inform the handler that we are going to close tables that are locked and may have (at least in Maria) be part of an active transaction.
Fix for Bug#39227 Maria: crash with ALTER TABLE PARTITION
include/my_base.h:
Added HA_EXTRA_PREPARE_FOR_FORCED_CLOSE for signaling the handler that the file will be forced closed
mysql-test/r/maria.result:
Test cases for bugs fixed
mysql-test/t/maria.test:
Test cases for bugs fixed
sql/ha_partition.cc:
Added support for the new extra flag: HA_EXTRA_PREPARE_FOR_FORCED_CLOSE (Bug #39226)
Ensure that we call extra() for HA_EXTRA_PREPARE_FOR_DROP (Bug#39227)
sql/sql_base.cc:
Call HA_EXTRA_PREPARE_FOR_FORCED_CLOSE for tables that are locked but we are going to force close without doing a commit
storage/maria/ma_extra.c:
If HA_EXTRA_PREPARE_FOR_FORCED_CLOSE is called and the table is part of a transaction, remove the table from beeing part of a transaction. This is safe as this is only used as part of flush tables or when the table is not part of a transaction
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.
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.
MyISAM blocks index usage for bulk insert into zero-records tables.
See ha_myisam::start_bulk_insert() lines from
...
if (file->state->records == 0 ...
...
That causes problems for partition engine when some partitions have records some not
as the engine uses same access method for all partitions.
Now partition engine doesn't call index_first/index_last
for empty tables.
per-file comments:
mysql-test/r/partition.result
Bug#38005 Partitions: error with insert select.
test result
mysql-test/t/partition.test
Bug#38005 Partitions: error with insert select.
test case
sql/ha_partition.cc
Bug#38005 Partitions: error with insert select.
ha_engine::index_first and
ha_engine::index_last not called for empty tables.
MyISAM blocks index usage for bulk insert into zero-records tables.
See ha_myisam::start_bulk_insert() lines from
...
if (file->state->records == 0 ...
...
That causes problems for partition engine when some partitions have records some not
as the engine uses same access method for all partitions.
Now partition engine doesn't call index_first/index_last
for empty tables.
per-file comments:
mysql-test/r/partition.result
Bug#38005 Partitions: error with insert select.
test result
mysql-test/t/partition.test
Bug#38005 Partitions: error with insert select.
test case
sql/ha_partition.cc
Bug#38005 Partitions: error with insert select.
ha_engine::index_first and
ha_engine::index_last not called for empty tables.
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).
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.
Removes the regression bug#38751.
sql/ha_partition.cc:
post push fix for bug#38804 (back port of bug#33479)
Removes the regression bug#38751.
archive relies on a ha_archive::info call to flush data before
the copy takes place in alter table.
This ensures that all partitions gets a info call, without having
to always forward info(HA_STATUS_AUTO) to all partitions.
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
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.
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).
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.
post push fix for bug#20129, test failed due to non existing
source files.
mysql-test/Makefile.am:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... complains that
partition is corrupt
Test parts.partition_repair_myisam failed because the corrupted
pre fabricated files was not included in the dist-file.
mysql-test/suite/parts/r/partition_special_innodb.result:
Bug#34604: hander::ha_rnd_end(): Assertion inited==RND failed
updated result file
mysql-test/suite/parts/t/partition_special_innodb-master.opt:
Bug#34604: hander::ha_rnd_end(): Assertion inited==RND failed
Added parameter to speed up the test.
Set to 2 seconds to be working on slow machines.
mysql-test/suite/parts/t/partition_special_innodb.test:
Bug#34604: hander::ha_rnd_end(): Assertion inited==RND failed
Added test for verifying the bug (without the patch in
ha_partition.cc, this crashes a debug compiled server)
sql/ha_partition.cc:
Bug#34604: hander::ha_rnd_end(): Assertion inited==RND failed
In some cases error was not properly propagated through
ha_partition::rnd_next.
Will now return the error code from the partitions rnd_next and
update m_part_spec.start_part and m_last_part properly.
This makes the inited state to be correct.
Bug#35161
Fixed memory leak when failing to open a partition.
Bug#20129
Added tests for verifying REPAIR PARTITION.
mysql-test/std_data/parts/t1_will_crash#P#p1_first_1024.MYD:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test
Created by:
CREATE TABLE t1_will_crash (
a VARCHAR(255),
b INT,
c LONGTEXT,
PRIMARY KEY (a, b))ENGINE=MyISAM
PARTITION BY HASH (b)
PARTITIONS 7;
INSERT INTO t1_will_crash VALUES ...
and then
head -c 1024 var/master-data/test/t1_will_crash#P#p1.MYD
into this file.
mysql-test/std_data/parts/t1_will_crash#P#p2.MYD:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test)
copy of file right after _mi_mark_file_changed in mi_write
was done.
mysql-test/std_data/parts/t1_will_crash#P#p2.MYI:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test)
copy of file right after _mi_mark_file_changed in mi_write
was done.
mysql-test/std_data/parts/t1_will_crash#P#p3.MYI:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test)
copy of file right after *share->write_record was done.
mysql-test/std_data/parts/t1_will_crash#P#p4.MYI:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test)
copy of file right after flush_cached_blocks
mysql-test/std_data/parts/t1_will_crash#P#p6.MYD:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test)
copy of file right after _mi_write_part_record in
write_dynamic_record returned for the first time.
mysql-test/std_data/parts/t1_will_crash#P#p6_2.MYD:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test)
copy of file right after _mi_write_part_record in
write_dynamic_record returned for the second time.
mysql-test/std_data/parts/t1_will_crash#P#p6_3.MYD:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
(see mysql-test/suite/parts/t/partition_repair_myisam.test)
copy of file right after _mi_write_part_record in
write_dynamic_record returned for the third time.
(data file fully updated).
mysql-test/suite/parts/r/partition_recover_myisam.result:
Bug#35161
Renamed since it was a test of recover
and to make repair free for use without
--myisam-recover
mysql-test/suite/parts/r/partition_repair_myisam.result:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
New result file for testing CHECK/REPAIR of partitioned tables
mysql-test/suite/parts/t/partition_recover_myisam-master.opt:
Bug#35161
Renamed since it was a test of recover
and to make repair free for use without
--myisam-recover
mysql-test/suite/parts/t/partition_recover_myisam.test:
Bug#35161
Renamed since it was a test of recover
and to make repair free for use without
--myisam-recover
mysql-test/suite/parts/t/partition_repair_myisam.test:
Bug#20129: ALTER TABLE ... REPAIR PARTITION ... not working
New test file for testing CHECK/REPAIR of partitioned tables
sql/ha_partition.cc:
Bug#35161
Fix of memory leak when open of partition failed.
update accross partitions.
It's not Innodb-specific bug.
ha_partition::update_row() didn't set
table->timestamp_field_type= TIMESTAMP_NO_AUTO_SET when
orig_timestamp_type == TIMESTAMP_AUTO_SET_ON_INSERT.
So that a partition sets the timestamp field when a record
is moved to a different partition.
Fixed by doing '= TIMESTAMP_NO_AUTO_SET' unconditionally.
Also ha_partition::write_row() is fixed in same way as now
Field_timestamp::set() is called twice in SET_ON_INSERT case.
(Chad queues this patch on demand by Trudy/Davi.)
mysql-test/r/partition.result:
Bug#38272 timestamps fields incorrectly defaulted on update accross partitions.
test result
mysql-test/t/partition.test:
Bug#38272 timestamps fields incorrectly defaulted on update accross partitions.
test case
sql/ha_partition.cc:
Bug#38272 timestamps fields incorrectly defaulted on update accross partitions.
Do table->timestamp_field_type= TIMESTAMP_NO_AUTO_SET unconditionally
in ha_partition::update_row and ::write_row()
