Analysis:
The cause of the valgrind warning was an attempt to evaluate a Field that was not yet read.
The reason was that on one hand Item_func_isnotnull was marked as constant by
Item_func_isnotnull::update_used_tables, and this allowed eval_const_cond() to be called.
On the other hand Item_func_isnotnull::val_int() evaluated its argument as if it was not
constant.
Solution:
The fix make sure that Item_func_isnotnull::val_int() doesn't evaluate its argument when
it is constant and cannot be NULL, because the result is known in this case.
STATUS OF ROLLBACKED TRANSACTION" and bug #17054007 - "TRANSACTION
IS NOT FULLY ROLLED BACK IN CASE OF INNODB DEADLOCK".
The problem in the first bug report was that although deadlock involving
metadata locks was reported using the same error code and message as InnoDB
deadlock it didn't rollback transaction like the latter. This caused
confusion to users as in some cases after ER_LOCK_DEADLOCK transaction
could have been restarted immediately and in some cases rollback was
required.
The problem in the second bug report was that although InnoDB deadlock
caused transaction rollback in all storage engines it didn't cause release
of metadata locks. So concurrent DDL on the tables used in transaction was
blocked until implicit or explicit COMMIT or ROLLBACK was issued in the
connection which got InnoDB deadlock.
The former issue has stemmed from the fact that when support for detection
and reporting metadata locks deadlocks was added we erroneously assumed
that InnoDB doesn't rollback transaction on deadlock but only last statement
(while this is what happens on InnoDB lock timeout actually) and so didn't
implement rollback of transactions on MDL deadlocks.
The latter issue was caused by the fact that rollback of transaction due
to deadlock is carried out by setting THD::transaction_rollback_request
flag at the point where deadlock is detected and performing rollback
inside of trans_rollback_stmt() call when this flag is set. And
trans_rollback_stmt() is not aware of MDL locks, so no MDL locks are
released.
This patch solves these two problems in the following way:
- In case when MDL deadlock is detect transaction rollback is requested
by setting THD::transaction_rollback_request flag.
- Code performing rollback of transaction if THD::transaction_rollback_request
is moved out from trans_rollback_stmt(). Now we handle rollback request
on the same level as we call trans_rollback_stmt() and release statement/
transaction MDL locks.
STATUS OF ROLLBACKED TRANSACTION" and bug #17054007 - "TRANSACTION
IS NOT FULLY ROLLED BACK IN CASE OF INNODB DEADLOCK".
The problem in the first bug report was that although deadlock involving
metadata locks was reported using the same error code and message as InnoDB
deadlock it didn't rollback transaction like the latter. This caused
confusion to users as in some cases after ER_LOCK_DEADLOCK transaction
could have been restarted immediately and in some cases rollback was
required.
The problem in the second bug report was that although InnoDB deadlock
caused transaction rollback in all storage engines it didn't cause release
of metadata locks. So concurrent DDL on the tables used in transaction was
blocked until implicit or explicit COMMIT or ROLLBACK was issued in the
connection which got InnoDB deadlock.
The former issue has stemmed from the fact that when support for detection
and reporting metadata locks deadlocks was added we erroneously assumed
that InnoDB doesn't rollback transaction on deadlock but only last statement
(while this is what happens on InnoDB lock timeout actually) and so didn't
implement rollback of transactions on MDL deadlocks.
The latter issue was caused by the fact that rollback of transaction due
to deadlock is carried out by setting THD::transaction_rollback_request
flag at the point where deadlock is detected and performing rollback
inside of trans_rollback_stmt() call when this flag is set. And
trans_rollback_stmt() is not aware of MDL locks, so no MDL locks are
released.
This patch solves these two problems in the following way:
- In case when MDL deadlock is detect transaction rollback is requested
by setting THD::transaction_rollback_request flag.
- Code performing rollback of transaction if THD::transaction_rollback_request
is moved out from trans_rollback_stmt(). Now we handle rollback request
on the same level as we call trans_rollback_stmt() and release statement/
transaction MDL locks.
After single row substitutions there might appear new equalities.
They should be properly propagated to all AND/OR levels the WHERE
condition. It's done now with an additional call of remove_eq_conds().
This patch almost totally revised the patch for bug mdev-4177.
The latter had too many defects. In particular, it did not
propagate multiple equalities formed when merging a degenerate
disjunct into underlying AND formula.
This a an old legacy performance bug.
When a very selective range scan existed for the second table in a join,
and, at the same time, there was another range condition depending on the
fields of the first table, the optimizer chose a plan with
'Range checked for each record'. This plan was extremely inefficient in
comparison with the regular selective range scan.
As a matter of fact the range scan chosen for each record was the same as
that selective range scan.
Changed the test case for bug 24776 to preserve the old output for explain.
MDEV-4812 Valgrind warnings (Invalid write) in dynamic_column_update_many on COLUMN_ADD
Fixed problem of working on wrong data (do not allow offset to out of string length).
- Modify the way Item_cond::fix_fields() and Item_cond::eval_not_null_tables()
calculate bitmap for Item_cond_or::not_null_tables():
if they see a "... OR inexpensive_const_false_item OR ..." then the item can
be ignored.
- Updated test results. There can be more warnings produced since parts of WHERE
are evaluated more times.
In the case of loose scan used as input for order by, end_send()
didn't detect correctly that a loose scan was used, and didn't copy
the non-aggregated fields from the temp table used for ORDER BY.
The fix uses the fact that the quick select used for sorting is
attached to JOIN::pre_sort_join_tab instead of JOIN::join_tab.
Apply the patch from Patryk Pomykalski:
- create_internal_tmp_table_from_heap() will now return information whether
the last row that we tried to write was a duplicate row.
(mysql-5.6 also has this change)
- merge_same_index_scans() may put the same SEL_ARG tree in multiple result plans.
make it call incr_refs() on the SEL_ARG trees that it does key_or() on, because
key_or(sel_arg_tree_1, sel_arg_tree_2) call may invalidate SEL_ARG trees pointed
by sel_arg_tree_1 and sel_arg_tree_2.
MDEV-4643 MariaDB crashes consistently when trying a SELECT on VIEW with a UNION and an additional JOIN in SELECT
open derived temp tables *before* trying QUICK_SELECT for them,
handler::multi_range_read_info() needs an open table.
Cleanup: remove TIME_FUZZY_DATE.
Introduce TIME_FUZZY_DATES which means "very fuzzy, the resulting
value is only used for comparison. It can be invalid date, fine, as long as it can be
compared".
Updated many tests results (they're better now).
Item_func_min_max::get_date() did not check the
returned value against the fuzzy_date flags, so
it could return a bad value to the caller that
expects a good date (e.h. CONVERT_TZ).
modified:
mysql-test/r/type_date.result
mysql-test/r/type_datetime.result
mysql-test/r/type_time.result
mysql-test/t/type_date.test
mysql-test/t/type_datetime.test
mysql-test/t/type_time.test
sql/item_func.cc
sql/item_timefunc.cc
sql/mysql_priv.h
sql/time.cc
Also, fixing a bug in STR_TO_DATE(). It erroneously returned
error in strict mode for dates like '0000-01-01'
(zero year, but non-zero month and day).
According to the manual:
- NO_ZERO_DATE disallows 0000-00-00 (all date parts are zeros)
- NO_ZERO_IN_DATE disallows zero month (YYYY-00-DD) or day (YYYY-MM-00).
0000-01-01 is a valid date, even in strict mode.
modified:
mysql-test/r/func_time.result
mysql-test/r/strict.result
mysql-test/t/func_time.test
mysql-test/t/strict.test
sql/item_timefunc.cc
sql/sql_time.h
pending merges:
Alexander Barkov 2013-06-17 MDEV-4635 Crash in UNIX_TIMESTAMP(STR_TO_DAT...
TO INCONSISTENCY
PROBLEM
--------
When we drop a partitoned table , we first gather the
information about partitions in the table from the
table_name.par file and store it in an internal data
structure.Then we delete this file and the data in
the table. If the server crashes after deleting the
file,then after recovering we cannot access the table
.Even we cannot drop the table ,because drop algorithm
requires par file to read the partition information.
FIX
---
1. We move the part of deleting par file after deleting
all the table data from the storage egine.
2. During drop operation if we detect that the par
file is missing then we delete the .frm file,since
there is no way of recovering without par file.
[Approved by Mattias rb#2576 ]
TO INCONSISTENCY
PROBLEM
--------
When we drop a partitoned table , we first gather the
information about partitions in the table from the
table_name.par file and store it in an internal data
structure.Then we delete this file and the data in
the table. If the server crashes after deleting the
file,then after recovering we cannot access the table
.Even we cannot drop the table ,because drop algorithm
requires par file to read the partition information.
FIX
---
1. We move the part of deleting par file after deleting
all the table data from the storage egine.
2. During drop operation if we detect that the par
file is missing then we delete the .frm file,since
there is no way of recovering without par file.
[Approved by Mattias rb#2576 ]
