Both these two bugs happened due to the following problem.
When a view column is referenced in the query an Item_direct_view_ref
object is created that is refers to the Item_field for the column.
All references to the same view column refer to the same Item_field.
Different references can belong to different AND/OR levels and,
as a result, can be included in different Item_equal object.
These Item_equal objects may include different constant objects.
If these constant objects are substituted for the Item_field created
for a view column we have a conflict situation when the second
substitution annuls the first substitution. This leads to
wrong result sets returned by the query. Bug #724942 demonstrates
such an erroneous behaviour.
Test case of the bug #717577 produces wrong result sets because best
equal fields of the multiple equalities built for different OR levels
of the WHERE condition differs. The subsitution for the best equal field
in the second OR branch overwrites the the substitution made for the
first branch.
To avoid such conflicts we have to substitute for the references
to the view columns rather than for the underlying field items.
To make such substitutions possible we have to include into
multiple equalities references to view columns rather than
field items created for such columns.
This patch modifies the Item_equal class to include references
to view columns into multiple equality objects. It also performs
a clean up of the class methods and adds more comments. The methods
of the Item_direct_view_ref class that assist substitutions for
references to view columns has been also added by this patch.
-fimplicit-termplates must be in CXXFLAGS not in handlersocket_la_CXXFLAGS.
otehrwise automake puts it in the command line too early to override
global -fno-implicit-templates
- Let advance_sj_state() save the value of JOIN::cur_dups_producing_tables
in POSITION::prefix_dups_producing_tables, and restore_sj_state() restore
it.
- "Using MRR" is no longer shown with range access.
- Instead, both range and BKA accesses will show one of the following:
= "Rowid-ordered scan"
= "Key-ordered scan"
= "Key-ordered Rowid-ordered scan"
depending on whether DS-MRR implementation will do scan keys in order, rowids in order,
or both.
- The patch also introduces a way for other storage engines/MRR implementations to
pass information to EXPLAIN output about the properties of employed MRR scans.
Analysis:
There are two code paths through which JOIN::exec may produce
an all-NULL row for an empty result set. One goes via the
function return_zero_rows(), when query processing detectes
early that the where clause is false, the other one is via
do_select() in the case of join execution.
In the case of do_select(), the problem was that the executioner
didn't set TABLE::null_row to 1. As result when sending the only
result row, the evaluation of each field didn't detect that all
non-aggregated fields are NULL, because Field::is_null returned
true, after checking that field->table->null_row was false.
Given that the each non-aggregated field was not considered NULL,
select_result::send_data sent whatever was in the buffer of each
field. However, since there was no actual data in the field buffer,
send_data() accessed and sent whatever junk was in the field's
data buffer.
Solution:
Similar to the analogous case in return_zero_rows() mark all
tables that their current row is NULL before sending the
artificailly created NULL row.
Analysis:
A query with implicit grouping is one with aggregate functions and
no GROUP BY clause. MariaDB inherits from MySQL an SQL extenstion
that allows mixing aggregate functions with non-aggregate fields.
If a query with such mixed select clause produces an empty result
set, the meaning of aggregate functions is well defined - either
NULL (MIN, MAX, etc.), or 0 (count(*)). However the non-aggregated
fields must also have some value, and the only reasonable value in
the case of empty result is NULL.
The cause of the many wrong results was that if a field is declared
as non-nullable (e.g. because it is a PK or NOT NULL), the semantic
analysis and the optimization phases treat this field as non-nullable,
and generate all related query plan elements based on this assumption.
Later during execution, these incorrectly configured/generated query
plan elements result in a wrong result because the selected fields
are not null due to the not-null assumption during optimization.
Solution:
Detect before the context analysys phase that a query uses implicit
grouping with mixed aggregates/non-aggregates, and set all fields
as nullable. The parser already walks the SELECT clause, and
already sets Item::with_sum_func for Items that reference aggreagate
functions. The patch adds a symmetric Item::with_field so that all
Items that reference an Item_field are marked during their
construction at parse time in the same way as with aggregate function
use.
Changed test suite to use --log-basename (to get the code tested)
Added --sync-sys=1 to test suite to speed it up.
Better error messages if something goes wrong with mysql_install_db
mysql-test/Makefile.am:
Removed not existing directory
mysql-test/lib/My/ConfigFactory.pm:
Use log-basename
We had to also set 'log_error' as some test was explicitely using the old name
Added 'sync-sys=1' to speed up test suite
mysql-test/r/variables-notembedded.result:
Updated test results (variable relay_log is now set)
mysql-test/suite/binlog/t/binlog_delete_and_flush_index-master.opt:
Force specific names for some log files.
mysql-test/suite/binlog/t/binlog_index-master.opt:
Force specific names for some log files.
mysql-test/suite/binlog/t/binlog_stm_unsafe_warning-master.opt:
Force specific names for some log files.
mysql-test/suite/binlog/t/binlog_stm_unsafe_warning.test:
Better error message if something goes wrong
mysql-test/suite/rpl/r/rpl_flushlog_loop.result:
Updated results
mysql-test/suite/rpl/rpl_1slave_base.cnf:
Use --log-basename
scripts/mysql_install_db.sh:
More information to --help
Write url to knowledge base if something goes wrong
Fail at once if we can't create a database directory (no reason to continue and write a screenful of not related text)
scripts/mysqld_safe.sh:
Also allow one to use --data for --datadir (common shortening)
Added support for --log-basename
Fail at once if we can't create a log directory
Fixed bug where we used a pid file name without '.pid' extension
sql/log.cc:
Create a log file name trough my_once_alloc() (To get it automaticly freed at exit)
sql/mysql_priv.h:
Added new prototype
sql/mysqld.cc:
Added support for --log-basename
Better help for a lot of log-filename related variables.
sql/rpl_rli.cc:
Write information that one can use --log-basename
sql/set_var.cc:
Add log_basename as a readonly variable
Implement binlog_optimize_thread_scheduling option to allow benchmarking the
effect of running commit_ordered() for multiple transactions all in one
thread.
Analysis (BUG#719198):
The assert failed because the execution code for
partial matching is designed with the assumption that
NULLs on the left side are detected as early as possible,
and a NULL result is returned before any lookups are
performed at all.
However, in the case of an Item_cache object on the left
side, null was not detected properly, because detection
was done via Item::is_null(), which is not implemented at
all for Item_cache, and resolved to the default Item::is_null()
which always returns FALSE.
Solution:
Imlpement Item::is_null().
******
Analysis (BUG#730604):
The method Item_field::is_null() determines if an item is NULL from its
Item_field::field object. However, for Item_fields that represent internal
temporary tables, Item_field::field represents the field of the original
table that was the source for the temporary table (in this case t1.f3).
Both in the committed test case, and in the original bug report the current
value of t1.f3 is not NULL. This results in an incorrect count of NULLs
for this column. As a consequence, all related Ordered_key buffers are
allocated with incorrect sizes. Depending on the exact query and data,
these incorrect sizes result in various crashes or failed asserts.
Solution:
The correct value of the current field of the internal temp table is
in Item_field::result_field. This value is determined by
Item::is_null_result().
Analysis:
The assert failed because the execution code for
partial matching is designed with the assumption that
NULLs on the left side are detected as early as possible,
and a NULL result is returned before any lookups are
performed at all.
However, in the case of an Item_cache object on the left
side, null was not detected properly, because detection
was done via Item::is_null(), which is not implemented at
all for Item_cache, and resolved to the default Item::is_null()
which always returns FALSE.
Solution:
Use the property Item::null_value instead of is_null(), which
is properly updated for Item_cache objects as well.
If join condition is of the form <t2.key>=<t1.no_key> then the server
performs no index look-ups when looking for matching rows of t2 for
the rows from t1 with t1.no_key=NULL. It happens because the function
add_not_null_conds() injects an additional condition of the form
IS NOT NULL(<t1.no_key>) into the WHERE condition.
However if the join condition was of the form <t.key>=<outer_ref> no
additional null rejecting predicate was generated. This could lead
to extra records in the result set if the value of <outer_ref> happened
to be NULL.
The new code injects null rejecting predicates of the form
IS NOT NULL(<outer_ref>) and evaluates them before the first row
the subquery is constructed.
- put the code that sets HA_NULL_PART bit back
- Fix test_if_ref/part_of_refkey() so that
= NULL-ability of lookup columns does not prevent the equality
from being removed (we now have early/late NULLs filtering which
will filter out NULL values)
= equality is not removed if it is ref_or_null access, and the value
of the lookup column can alternate between the lookup value and NULL.
- The problem was that Mrr_ordered_index_reader's interrupt_read() and resume_read() would
save and restore 1) index tuple 2) the rowid (as bytes returned by handler->position()). Clustered
primary key columns were not saved/restored.
They are not explicitly present in the index tuple (i.e. table->key_info[secondary_key].key_parts
doesn't list them), but they are actually there, in particular
table->field[clustered_primary_key_member].part_of_key(secondary_key) == 1. Index condition pushdown
code [correctly] uses the latter as inidication that pushed index condition can refer to clustered PK
members.
The fix was to make interrupt_read()/resume_read() to save/restore clustered primary key members as well,
so that we get correct values for them when evaluating pushed index condition.
[3rd attempt: remove the debugging aids, fix comments in testcase]
Analysis:
The reason for the crash was that the inner subquery was executed
via a scan on a final temporary table applied after all other
operations. This final operation is implemented by changing the
contents of the JOIN object of the subquery to represent a table
scan over the temp table. At the same time query optimization of
the outer subquery required evaluation of the inner subquery, which
happened before the actual EXPLAIN. The evaluation left the JOIN
object of the inner subquery in the changed state, where it represented
a table scan over a temp table, and EXPLAIN crashed because the temp
table is not associated with any table reference (TABLE_LIST object).
The reason the JOIN was not restored was because its saving/restoration
was controlled by the join->select_lex->uncacheable flag, which was
not set in the case of materialization.
Solution:
In the methods Item_in_subselect::[single | row]_value_transformer() set:
select_lex->uncacheable|= UNCACHEABLE_EXPLAIN;
In addition, for symmetry, change:
master_unit->uncacheable|= UNCACHEABLE_EXPLAIN;
instead of UNCACHEABLE_DEPENDENT because if a subquery was not
dependent initially, the changed methods do not change this
fact. The subquery may later become correlated if it is transformed
to an EXISTS query, but it may stay uncorrelated if executed via
materialization.
- Make DsMrr_impl::dsmrr_init() handle the case of
1. 1st MRR scan using DS-MRR strategy (i.e. doing key sorting and rowid sorting)
2. 2nd MRR scan getting a buffer that's too small to fit one key element
and one rowid element, and so falling back to default MRR implementation
In this case, dsmrr_init() is invoked with {primary_handler, secondary_handler}
initialized for DS-MRR scan and have to reset them to be initialized for the
default MRR scan.
(attempt 2, with simplified testcase)
- Make equality-substitution-for-ref-access code in JOIN::optimize() treat join_tab->ref.key_copy correctly
(in the way create_ref_for_key() has filled it).
The bug in the function print_keyuse() caused crashes if
hash join could be used. It happened because the function
ignored the fact that KEYUSE structures could be created
for hash joins as well.
- Make get_constant_key_infix() take into account that there may be SEL_TREEs with
type=SEL_ARG::MAYBE_KEY, which it cannot process, because they are not real ranges
but rather indications that we might have been able to construct a range if we had
values for some other tables' fields.
(check_quick_select() already has such check)
even in the cases when there existed range/index-merge scans that
were cheaper than the full table scan.
This was a defect/bug of the implementation of mwl #128.
Now hash join can work not only with full table scan of the joined
table, but also with full index scan, range and index-merge scans.
Accordingly, in the cases when hash join is used the column 'type'
in the EXPLAINs can contain now 'hash_ALL', 'hash_index', 'hash_range'
and 'hash_index_merge'. If hash join is coupled with a range/index_merge
scan then the columns 'key' and 'key_len' contain info not only on
the used hash index, but also on the indexes used for the scan.
- Linking now with g++ instead of gcc with 'compile-dist' to solve problems with handlersocket/client
- Fixed bug in heap tables when doing handler read next-prev over last row
BUILD/compile-dist:
- Linking now with g++ instead of gcc with 'compile-dist' to solve problems with handlersocket/client
cmd-line-utils/libedit/vi.c:
Fixed compiler warning about not checking return value for write
mysql-test/r/index_intersect.result:
Updated results (missed this file in my last push)
mysql-test/suite/handler/aria.result:
Updated test results
mysql-test/suite/handler/handler.inc:
Changed test to use read next/read prev on key where there are duplicates that can come in different order depending on system
Added testing of read next-prev over last row and read prev-next around first row
mysql-test/suite/handler/heap.result:
Updated test results
mysql-test/suite/handler/init.inc:
More rows to test
mysql-test/suite/handler/innodb.result:
Updated test results
mysql-test/suite/handler/interface.result:
Updated test results
mysql-test/suite/handler/myisam.result:
Updated test results
mysql-test/t/variables-big.test:
Fixed test to not fail on windows
mysql-test/valgrind.supp:
Removed not matching fun: to get rid of valgrind warning
storage/heap/hp_rfirst.c:
Added state so that we know if we have an active position in the index.
storage/heap/hp_rkey.c:
Added state so that we know if we have an active position in the index.
storage/heap/hp_rnext.c:
Handle reading several next after finding the last row (this caused a crash before)
storage/heap/hp_rprev.c:
Handle reading several prev after finding the first row (this caused a crash before)
storage/xtradb/buf/buf0buf.c:
Fixed compiler warning about uninitialized value
