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
and the original engine is disabled
Missing check that engine is available.
mysql-test/include/not_blackhole.inc:
new include file
mysql-test/r/partition_not_blackhole.result:
new result file
mysql-test/std_data/parts/t1_blackhole.frm:
blackhole partitioned table .frm file:
create table `t1` (`id` int primary key) engine=blackhole
partition by key () partitions 1;
mysql-test/std_data/parts/t1_blackhole.par:
.par file matching blackhole partitioned .frm
mysql-test/t/partition_not_blackhole-master.opt:
new master-opt to disable blackhole if compiled in.
mysql-test/t/partition_not_blackhole.test:
New test
sql/ha_partition.cc:
Added check that engine is available.
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
Problem was reporting wrong error
Fixed by adding a new error which better explain the problem.
mysql-test/r/partition_error.result:
Bug#49161: Out of memory; restart server and try again (needed 2 bytes)
Updated test result
mysql-test/t/partition_error.test:
Bug#49161: Out of memory; restart server and try again (needed 2 bytes)
Added test case
sql/ha_partition.cc:
Bug#49161: Out of memory; restart server and try again (needed 2 bytes)
Better error message. (used ER_UNKNOWN_ERROR to avoid merge
problems in mysql-trunk+)
concurrent I_S query
There were two problem:
1) MYSQL_LOCK_IGNORE_FLUSH also ignored name locks
2) there was a race between abort_and_upgrade_locks and
alter_close_tables
(i.e. remove_table_from_cache and
close_data_files_and_morph_locks)
Which allowed the table to be opened with MYSQL_LOCK_IGNORE_FLUSH flag
resulting in renaming a partition that was already in use,
which could cause the table to be unusable.
Solution was to not allow IGNORE_FLUSH to skip waiting for
a named locked table.
And to not release the LOCK_open mutex between the
calls to remove_table_from_cache and
close_data_files_and_morph_locks by merging the functions
abort_and_upgrade_locks and alter_close_tables.
mysql-test/suite/parts/r/partition_debug_sync_innodb.result:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added test result
mysql-test/suite/parts/t/partition_debug_sync_innodb-master.opt:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added test option
mysql-test/suite/parts/t/partition_debug_sync_innodb.test:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added test file
sql/authors.h:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Time to be acknowledged :)
sql/ha_partition.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added DEBUG_SYNC for deterministic testing
sql/mysql_priv.h:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Renamed function since merging alter_close_tables into
abort_and_upgrade_lock.
sql/sql_base.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Changed MYSQL_LOCK_IGNORE_FLUSH to not ignore name locks
(open_placeholder).
Merged alter_close_tables into abort_and_upgrade_locks
(and added _and_close_table to the name)
to not release LOCK_open between remove_table_from_cache
and close_data_files_and_morph_locks.
Added DEBUG_SYNC for deterministic testing.
sql/sql_partition.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Removed alter_close_tables, (merged it into
abort_and_upgrad_lock) so that LOCK_open never is released
between remove_table_from_cache and
close_data_files_and_morph_locks.
sql/sql_show.cc:
Bug#50561: ALTER PARTITIONS does not have adequate lock, breaks with
concurrent I_S query
Added DEBUG_SYNC for deterministic testing
auto_increment on duplicate entry
The bug was that when INSERT_ID was used and the storage
engine was told to release any reserved but not used
auto_increment values, it set the highest auto_increment
value to INSERT_ID.
The fix was to check if the auto_increment value was forced
by user (INSERT_ID) or by slave-thread, i.e. not auto-
generated. So that it is only allowed to release generated
values.
mysql-test/r/partition_error.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
updated result
mysql-test/suite/parts/inc/partition_auto_increment.inc:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added test
mysql-test/suite/parts/r/partition_auto_increment_archive.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that archive does only allow increasing
auto_increment values
mysql-test/suite/parts/r/partition_auto_increment_blackhole.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that blackhole accepts all inserts :)
mysql-test/suite/parts/r/partition_auto_increment_innodb.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that innodb rolls back inserts on error,
but keeps the auto_increment value.
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that memory and myisam inserts all rows
before the error.
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that memory and myisam inserts all rows
before the error.
mysql-test/suite/parts/r/partition_auto_increment_ndb.result:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added result, note that NDB does not seem to handle
INSERT_ID as other engines. (Martin will look into it).
mysql-test/t/partition_error.test:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
Added test
sql/ha_partition.cc:
Bug#50392: insert_id is not reset for partitioned tables
auto_increment on duplicate entry
If the next_insert_id comes from non generated (i.e
forced by INSERT_ID or slave-thread) then we cannot
lower the reserved auto_increment value, since it have
not reserved any values.
Problem was block_size on partitioned tables was not set,
resulting in keys_per_block was not correct which affects
the cost calculation for read time of indexes (including
cost for group min/max).Which resulted in a bad optimizer
decision.
Fixed by setting stats.block_size correctly.
mysql-test/r/partition_range.result:
Bug#48229: group by performance issue of partitioned table
Added result
mysql-test/t/partition_range.test:
Bug#48229: group by performance issue of partitioned table
Added test
sql/ha_partition.cc:
Bug#48229: group by performance issue of partitioned table
Added missing assignment of stats.block_size.
There was two problems:
The first was the symptom, caused by bad error handling in
ha_partition. It did not handle print_error etc. when
having no partitions (when used by dummy handler).
The second was the real problem that when dropping tables
it reused the table type (storage engine) from when the lock
was asked for, not the table type that it had when gaining
the exclusive name lock. So that it tried to delete tables
from wrong storage engines.
Solutions for the first problem was to accept some handler
calls to the partitioning handler even if it was not setup
with any partitions, and also if possible fallback
to use the base handler's default functions.
Solution for the second problem was to remove the optimization
to reuse the definition from the cache, instead always check
the frm-file when holding the LOCK_open mutex
(updated with a fix for a debug print crash and better
comments as required by reviewer, and removed optimization
to avoid reading the frm-file).
mysql-test/r/partition_debug_sync.result:
Bug#42438: Crash ha_partition::change_table_ptr
New result file using DEBUG_SYNC for deterministic results.
mysql-test/t/partition_debug_sync.test:
Bug#42438: Crash ha_partition::change_table_ptr
New test file using DEBUG_SYNC for deterministic results.
sql/ha_partition.cc:
Bug#42438: Crash ha_partition::change_table_ptr
allow some handler calls, used by error handling, even when
no partitions are setup. Fallback to default handling if possible.
sql/sql_base.cc:
Bug#42438: Crash ha_partition::change_table_ptr
Added DEBUG_SYNC point for deterministic test cases.
sql/sql_table.cc:
Bug#42438: Crash ha_partition::change_table_ptr
Always use the table type written in the .frm-file
(i.e. the current table type) when deleting a table.
Moved the check for log-table to not depend of the cache.
Added DEBUG_SYNC points for deterministic test cases.
Missing ha_rnd_end in copy_partitions, found due to a
DBUG_ASSERT in mysql-pe
sql/ha_partition.cc:
Post-push patch for bug#47343
Must call ha_rnd_end since ha_rnd_init has been called.
REORGANIZE PARTITION
There were several problems which lead to this this,
all related to bad error handling.
1) There was several bugs preventing the ddl-log to be used for
cleaning up created files on error.
2) The error handling after the copy partition rows did not close
and unlock the tables, resulting in deletion of partitions
which were in use, which lead InnoDB to put the partition to
drop in a background queue.
sql/ha_partition.cc:
Bug#47343: InnoDB fails to clean-up after lock wait timeout on
REORGANIZE PARTITION
Better error handling, if partition has been created/opened/locked
then make sure it is unlocked and closed before returning error.
The delete of the newly created partition is handled by the ddl-log.
sql/sql_parse.cc:
Bug#47343: InnoDB fails to clean-up after lock wait timeout on
REORGANIZE PARTITION
Fix a bug found when experimenting, thd could really be NULL here,
as mentioned in the function header.
sql/sql_partition.cc:
Bug#47343: InnoDB fails to clean-up after lock wait timeout on
REORGANIZE PARTITION
Used the correct .frm shadow name to put into the ddl-log.
Really use the ddl-log to handle errors.
sql/sql_table.cc:
Bug#47343: InnoDB fails to clean-up after lock wait timeout on
REORGANIZE PARTITION
Fixes of the ddl-log when used as error recovery (no crash).
When executing an entry from memory (not read from disk)
the name_len was not set correctly.
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.
backport for bug#44059 from mysql-pe to mysql-5.1-bugteam
Using the partition with most rows instead of first partition
to estimate the cardinality of indexes.
mysql-test/r/partition.result:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Added test result
mysql-test/t/partition.test:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Added test case
sql/ha_partition.cc:
Bug#44059: Incorrect cardinality of indexes on a partitioned table
Checking which partition that has the most rows, and using that
partition for HA_STATUS_CONST instead of first partition
is reached
Problem was bad error handling, leaving some new temporary
partitions locked and initialized and some not yet initialized
and locked, leading to a crash when trying to unlock the not
yet initialized and locked partitions
Solution was to unlock the already locked partitions, and not
include any of the new temporary partitions in later unlocks
mysql-test/r/partition_open_files_limit.result:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test result
mysql-test/t/partition_open_files_limit-master.opt:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test opt-file for testing when open_files_limit is reached
mysql-test/t/partition_open_files_limit.test:
Bug#46922: crash when adding partitions and open_files_limit
is reached
New test case testing when open_files_limit is reached
sql/ha_partition.cc:
Bug#46922: crash when adding partitions and open_files_limit
is reached
When cleaning up the partitions already locked need to be unlocked,
and not be unlocked/closed after cleaning up.
"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.
(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.
INSERT ... SELECT ...
Problem was that when bulk insert is used on an empty
table/partition, it disables the indexes for better
performance, but in this specific case it also tries
to read from that partition using an index, which is
not possible since it has been disabled.
Solution was to allow index reads on disabled indexes
if there are no records.
Also reverted the patch for bug#38005, since that was a workaround
in the partitioning engine instead of a fix in myisam.
mysql-test/r/partition.result:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
updated result file
mysql-test/t/partition.test:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
Added testcase
sql/ha_partition.cc:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
reverted the patch for bug#38005, since that was a workaround
around this problem, not needed after fixing it in myisam.
storage/myisam/mi_search.c:
Bug#46639: 1030 (HY000): Got error 124 from storage engine on
INSERT ... SELECT ...
Return HA_ERR_END_OF_FILE instead of HA_ERR_WRONG_INDEX
when there are no rows.
column on partitioned table
An assertion 'ASSERT_COULUMN_MARKED_FOR_READ' is failed if the query
is executed with index containing double column on partitioned table.
The problem is that assertion expects all the fields which are read,
to be in the read_set.
In this query only the field 'a' is in the readset as the tables in
the query are joined by the field 'a' and so the assertion fails
expecting other field 'b'.
Since the function cmp() is just comparison of two parameters passed,
the assertion is not required.
Fixed by removing the assertion in the double fields comparision
function and also fixed the index initialization to do ordered
index scan with RW LOCK which ensures all the fields from a key are in
the read_set.
Note: this bug is not reproducible with other datatypes because the
assertion doesn't exist in comparision function for other
datatypes.
mysql-test/r/partition.result:
Testcase for BUG#45816
mysql-test/t/partition.test:
Testcase for BUG#45816
sql/field.cc:
Removed the assertion ASSERT_COLUMN_MARED_FOR_READ in Field_double::cmp()
function
sql/ha_partition.cc:
Fixed index_int() method to make it initialize the read_set properly if
ordered index scan with RW lock is requested.
We disallow the partitioning of a log table. You could however
partition a table first, and then point logging to it. This is
not only against the docs, it also crashes the server.
We catch this case now.
mysql-test/r/partition.result:
results for 40281
mysql-test/t/partition.test:
test for 40281: show that trying to log to partitioned table fails rather
to crash the server
sql/ha_partition.cc:
Signal that we no longer support logging to partitioned tables,
as per the docs.
sql/sql_partition.cc:
Some commands like "USE ..." have no select, yet we may try
to parse partition info after their execution if user set a
partitioned table as log target. This shouldn't lead to a
NULL-deref/crash.
Problem was that a failing rename just left the partitions at the state
it was at the failure.
Solution was to try to revert the started rename if a failure occured.
mysql-test/r/partition_not_embedded.result:
Bug#30102: Rename table does corrupt tables with partition files on failure
New result file
mysql-test/t/partition_not_embedded.test:
Bug#30102: Rename table does corrupt tables with partition files on failure
New test file
(list_files does not report the files in embedded)
sql/ha_partition.cc:
Bug#30102: Rename table does corrupt tables with partition files on failure
Better error handling for rename partitions (reverting the started rename
operation)
Different order of files for delete.
sql/handler.cc:
Bug#30102: Rename table does corrupt tables with partition files on failure
Tries to remove as many table files as possible
if the first delete succeeds.
the auto_increment value
This is an alternative patch that instead of allowing RECREATE TABLE
on TRUNCATE TABLE it implements reset_auto_increment that is called
after delete_all_rows.
Note: this bug was fixed by Mattias Jonsson:
Pusing this patch: http://lists.mysql.com/commits/70370
mysql-test/suite/parts/r/partition_auto_increment_memory.result:
Bug#35111: Truncate a MyISAM partitioned table does not reset
the auto_increment value
mysql-test/suite/parts/r/partition_auto_increment_myisam.result:
Bug#35111: Truncate a MyISAM partitioned table does not reset
the auto_increment value
sql/ha_partition.cc:
Bug#35111: Truncate a MyISAM partitioned table does not reset
the auto_increment value
Added reset_auto_increment, to be used after delete_all_rows
to simulate truncate.
storage/heap/ha_heap.cc:
Bug#35111: Truncate a MyISAM partitioned table does not reset
the auto_increment value
Added reset_auto_increment, to be used after delete_all_rows
to simulate truncate
storage/heap/ha_heap.h:
Bug#35111: Truncate a MyISAM partitioned table does not reset
the auto_increment value
Added reset_auto_increment, to be used after delete_all_rows
to simulate truncate
storage/myisam/ha_myisam.cc:
Bug#35111: Truncate a MyISAM partitioned table does not reset
the auto_increment value
Added reset_auto_increment, to be used after delete_all_rows
to simulate truncate.
storage/myisam/ha_myisam.h:
Bug#35111: Truncate a MyISAM partitioned table does not reset
the auto_increment value
Added reset_auto_increment, to be used after delete_all_rows
to simulate truncate.
Problem is that DATA_FREE in SHOW TABLE STATUS
is not correct when not using innodb_file_per_table.
The solution is to use I_S.PARTITIONS instead.
This is only a small fix for correcting mean record length and
always return 0 if the table is empty.
sql/ha_partition.cc:
Bug#36312: InnoDB DATA_FREE BUG?
This is only a small fix for correcting mean record length and
always return 0 if the table is empty.
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
'lock wait timeout exceeded'
Problem was a bug in the implementation of scan in partitioning
which masked the error code from the partition's handler.
Fixed by returning the value from the underlying handler.
mysql-test/suite/parts/r/partition_special_innodb.result:
Bug#40515: Query on a partitioned table does not return
'lock wait timeout exceeded'
Updated test result
mysql-test/suite/parts/t/partition_special_innodb.test:
Bug#40515: Query on a partitioned table does not return
'lock wait timeout exceeded'
Updated test case for covering the bug.
sql/ha_partition.cc:
Bug#40515: Query on a partitioned table does not return
'lock wait timeout exceeded'
Removing redeclaration of result variable,
which resulted in never returning the correct return value.
mysql-test/t/partition.test
sql/ha_partition.cc
Bug#40954: Crash in MyISAM index code with concurrency test using partitioned tables
Problem was usage of read_range_first with an empty key.
Solution was to not to give a key if it was empty. (real author Mattias Jonsson)
storage/archive/archive_reader.c
client/mysqlslap.c
Aligned the copyright texts output from "--version" of tools, to
let internal tools be able to change them if needed.
storage/ndb/test/tools/connect.cpp
storage/ndb/test/run-test/atrt.hpp
Corrected a few GPL headers not restricted to GPL version 2
Makefile.am
Added missing --report-features to the 'test-bt-fast' target
support-files/mysql.spec.sh
Reversed the removal of the "%define license GPL" in as internal
tools depended on it
Problem was usage of read_range_first with an empty key.
Solution was to not to give a key if it was empty.
mysql-test/r/partition.result:
Bug#40954: Crash in MyISAM index code with concurrency test using partitioned tables
Updated test result.
mysql-test/t/partition.test:
Bug#40954: Crash in MyISAM index code with concurrency test using partitioned tables
Added test case
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).
