The thd->lex->part_info should be kept intact during PS
execution. Or the second execution gets that modified part_info.
Let's modify ths->work_part_info instead.
Spider patches 026 (MDEV-7723), 031 (MDEV-7727) and 058 (MDEV-12532)
This allows the storage engine to internally compute sum and count
operations.
- Enhance sum items to be able to store the sum value directly.
- return_record_by_parent() is enabled in spider as
HANDLER_HAS_DIRECT_AGGREGATE is defined
- Added spd_environ.h to spider. This is loaded first to ensure that all
MariaDB specific defines that are used by include files are properly
defined.
- This code is tested by the existing spider tests direct_aggregate.test
and direct_aggregate_part.test and also partition.test
Other things:
- Cleanup of allocated bitmaps done in open(), which
simplifies init_partition_bitmaps()
- Add needed defines in ha_spider.cc to enable new spider code
- Fixed some DBUG_PRINT() to be consistent with normal code
- Removed end space
- The changes in test cases partition_innodb, partition_range,
partition_pruning etc are becasue partitions can now more exactly
calculate the number of rows in a range.
Contains spider patches:
014,015,023,033,035,037,040,042,044,045,049,050,051,053,059
MySQL Bug#71095: Wrong results with PARTITION BY LIST COLUMNS()
MySQL Bug#72803: Wrong "Impossible where" with LIST partitioning
MDEV-6240: Wrong "Impossible where" with LIST partitioning
- Backprot the fix from MySQL Bug#71095.
MDEV-5555: Incorrect index_merge on BTREE indices
- In ha_partition, make ordered index reads return rows in rowid order
when index columns are the same.
(This is attempt at fix#2) (re-commit with fixed typo)
- Moved the testcase from partition_test to partition_innodb.test where it can really work.
- Made ordered index scans over ha_partition tables to satisfy ROR property for
the case where underlying table uses extended keys.
includes:
* remove some remnants of "Bug#14521864: MYSQL 5.1 TO 5.5 BUGS PARTITIONING"
* introduce LOCK_share, now LOCK_ha_data is strictly for engines
* rea_create_table() always creates .par file (even in "frm-only" mode)
* fix a 5.6 bug, temp file leak on dummy ALTER TABLE
Syntax modified to allow statements:
ALTER TABLE ADD/DROP COLUMN
ALTER TABLE ADD/DROP INDEX
ALTER TABLE ADD/DROP FOREIGN KEY
ALTER TABLE ADD/DROP PARTITION
ALTER TABLE CHANGE COLUMN
ALTER TABLE MODIFY COLUMN
DROP INDEX
to have IF (NOT) EXISTS options.
Appropriate implementations added to mysql_alter_table().
per-file comments:
mysql-test/r/alter_table.result
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
test result updated.
mysql-test/r/fulltext.result
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
mysql-test/r/partition.result
test result updated.
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
mysql-test/t/alter_table.test
tests added.
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
mysql-test/t/fulltext.test
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
tests added.
mysql-test/t/partition.test
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
tests added.
sql/field.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
create_if_not_exists field added.
sql/field.h
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
create_if_not_exists field added.
sql/partition_info.h
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
has_unique_name made public.
sql/sp_head.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
sql/sql_class.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
create_if_not_exists inited.
sql/sql_class.h
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
create_if_not_exists inited.
sql/sql_lex.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
check_exists inited.
sql/sql_lex.h
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
check_exists inited.
sql/sql_parse.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
check_exists inited.
sql/sql_table.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
handle_if_exists_options() added.
it's called in mysql_alter_table().
sql/sql_trigger.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
check_exists instead of drop_if_exists.
sql/sql_view.cc
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
check_exists instead of drop_if_exists.
sql/sql_yacc.yy
MDEV-318 IF (NOT) EXIST clauses for ALTER TABLE (MWL #252).
sintax modified.
mysql-test/r/partition.result:
Added test case
mysql-test/t/partition.test:
Added test case
sql/ha_partition.cc:
Removed printing of not initialized variable
storage/maria/ha_maria.cc:
Don't copy variables that are not initialized
mysql-test/r/partition.result:
Added test case
mysql-test/t/partition.test:
Added test case
sql/sql_partition.cc:
Do mysql_trans_prepare_alter_copy_data() after all original tables are locked.
(We don't want to disable transactions for the original tables, that still may be in the cache)
sql/sql_table.cc:
Fixed two wrong DBUG_ENTER
Analysis:
The problem in the original MySQL bug is that the range optimizer
performs its analysis in a separate MEM_ROOT object that is freed
after the range optimzier is done. During range analysis get_mm_tree
calls Item_func_like::select_optimize, which in turn evaluates its
right argument. In the test case the right argument is a subquery.
In MySQL, subqueries are optimized lazyly, thus the call to val_str
triggers optimization for the subquery. All objects needed by the
subquery plan end up in the temporary MEM_ROOT used by the range
optimizer. When execution ends, the JOIN::cleanup process tries to
cleanup objects of the subquery plan, but all these objects are gone
with the temporary MEM_ROOT. The solution for MySQL is to switch the
mem_root.
In MariaDB with the patch for bug lp:944706, all constant subqueries
that may be used by the optimization process are preoptimized. Therefore
Item_func_like::select_optimize only triggers subquery execution, and
the above problem is not present.
The patch however adds a test whether the evaluated right argument of
the LIKE predicate is expensive. This is consistent with our approach
not to evaluate expensive expressions during optimization.
mysql-test/suite/innodb/t/group_commit_crash.test:
remove autoincrement to avoid rbr being used for insert ... select
mysql-test/suite/innodb/t/group_commit_crash_no_optimize_thread.test:
remove autoincrement to avoid rbr being used for insert ... select
mysys/my_addr_resolve.c:
a pointer to a buffer is returned to the caller -> the buffer cannot be on the stack
mysys/stacktrace.c:
my_vsnprintf() is ok here, in 5.5
Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP
The assert in 13580775 is visible in 5.6 only,
but shows that all versions are vulnerable.
13011410 crashes in all versions.
filesort tries to re-use the sort buffer between invocations in order to save
malloc/free overhead.
The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT.
added an assert that buffer properties (num_records, record_length) are
consistent between invocations. Indeed, they are not necessarily consistent.
Fix: re-allocate the sort buffer if properties change.
mysql-test/r/partition.result:
New tests.
mysql-test/t/partition.test:
New tests.
sql/filesort.cc:
If we already have allocated a sort buffer in a previous execution,
then verify that it is big enough for the current one.
sql/table.h:
Add sort_keys_size; Number of bytes allocated for the sort_keys buffer.
sql/sql_insert.cc:
CREATE ... IF NOT EXISTS may do nothing, but
it is still not a failure. don't forget to my_ok it.
******
CREATE ... IF NOT EXISTS may do nothing, but
it is still not a failure. don't forget to my_ok it.
sql/sql_table.cc:
small cleanup
******
small cleanup
The partitioning engine checked the auto_increment column even if it was not to be written,
triggering a DBUG_ASSERT.
Fixed by checking if table->write_set for that column was set.
Bug#28928: UNIX_TIMESTAMP() should be considered unary monotonic by partition pruning
Made UNIX_TIMESTAMP MONOTONIC_INCREASING when it have TIMESTAMP argument (only).
UPDATES THE TABLE ENTRIES (formerly 55385)
BUG#11764529: MULTI UPDATE+INNODB REPORTS ER_KEY_NOT_FOUND
IF A TABLE IS UPDATED TWICE (formerly 57373)
If multiple-table update updates a row through two aliases and
the first update physically moves the row, the second update will
fail to locate the row. This results in different errors
depending on storage engine:
* MyISAM: Got error 134 from storage engine
* InnoDB: Can't find record in 'tbl'
None of these errors accurately describe the problem.
Furthermore, since MyISAM is non-transactional, the update
executed first will be performed while the second will not.
In addition, for two equal multiple-table update statements,
one could succeed and the other fail based on whether or not
the record actually moved or not. This was inconsistent.
Two update operations may physically move a row:
1) Update of a column in a clustered primary key
2) Update of a column used to calculate which partition the
row belongs to
BUG#11764529 is about case 1) above, BUG#11762751 was about case 2).
The fix for these bugs is to return with an error if multiple-table
update is about to:
a) Update a table through multiple aliases, and
b) Perform an update that may physically more the row
in at least one of these aliases
This avoids
* partial updates as described for MyISAM above,
* provides the same error message that describes the actual problem
for all SEs
* inconsistent behavior where a statement fails or succeeds based on
e.g. the partitioning algorithm of the table.
mysql-test/r/multi_update.result:
Add test for bug#57373
mysql-test/r/multi_update_innodb.result:
Add test for bug#57373
mysql-test/r/partition.result:
Add test for bug#55385
mysql-test/t/multi_update.test:
Add test for bug#57373
mysql-test/t/multi_update_innodb.test:
Add test for bug#57373
mysql-test/t/partition.test:
Add test for bug#55385
sql/handler.cc:
Translate handler error HA_ERR_RECORD_DELETED to server error
sql/share/errmsg-utf8.txt:
New error message for multi-table update where the same table is updated multiple times.
sql/sql_update.cc:
Add function unsafe_key_update()
- Fixed some issues with partitions and connection_string, which also fixed lp:716890 "Pre- and post-recovery crash in Aria"
- Fixed wrong assert in Aria
Now need to merge with latest xtradb before pushing
sql/ha_partition.cc:
Ensure that m_ordered_rec_buffer is not freed before close.
sql/mysqld.cc:
Changed to use opt_stack_trace instead of opt_pstack.
Removed references to pstack
sql/partition_element.h:
Ensure that connect_string is initialized
storage/maria/ma_key_recover.c:
Fixed wrong assert
Regression introduced in bug#52455. Problem was that the
fixed function did not set the last used partition variable, resulting
in wrong partition used when storing the position of the newly
retrieved row.
Fixed by setting the last used partition in ha_partition::index_read_idx_map.
Bug#57071: EXTRACT(WEEK from date_col) cannot be allowed as partitioning function
There were functions allowed as partitioning functions
that implicit allowed cast. That could result in unacceptable
behaviour.
Solution was to check that the arguments of date and time functions
have allowed types (field and date/datetime/time depending on function).
mysql-test/r/partition.result:
Updated result
mysql-test/r/partition_error.result:
Updated result
mysql-test/suite/parts/inc/part_supported_sql_funcs_main.inc:
disabled test with not allowed arguments.
mysql-test/suite/parts/r/part_supported_sql_func_innodb.result:
Updated result
mysql-test/suite/parts/r/part_supported_sql_func_myisam.result:
Updated result
mysql-test/t/partition.test:
Fixed typo in bug number and removed non allowed function (bad argument)
mysql-test/t/partition_error.test:
Added tests to verify correct type of argument.
sql/item.h:
Renamed processor since it is no longer only for timezone
sql/item_func.h:
Added help functions for checking date/time/datetime arguments.
sql/item_timefunc.h:
Added processors for argument correctness
sql/sql_partition.cc:
renamed the processor for checking arguments.
It was possible to issue an ALTER TABLE ADD PRIMARY KEY on
an partitioned InnoDB table that failed and crashed the server.
The problem was that it succeeded to create the PK on at least
one partition, and then failed on a subsequent partition, due to
duplicate key violation. Since the partitions that already had added
the PK was not reverted all partitions was not consistent with the
table definition, which caused the crash.
The solution was to add a revert step to ha_partition::add_index()
that dropped the index for the already succeeded partitions, on failure.
mysql-test/r/partition.result:
updated result
mysql-test/t/partition.test:
Added test
sql/ha_partition.cc:
Only allow ADD/DROP flags in pairs, so that they can be reverted on failures.
If add_index() fails for a partition, revert (drop the index) for the previous
partitions.
sql/handler.h:
Added some extra info in a comment.
