Commit graph

7098 commits

Author SHA1 Message Date
Varun Gupta
6f4534e622 MDEV-14695: Assertion `n < m_size' failed in Bounds_checked_array<Element_type>::operator
In this issue we hit the assert because we are adding addition fields to the field JOIN::all_fields list. This
is done because  HEAP tables can't index BIT fields so  we need to use an additional hidden field for grouping because later it will be
converted to a LONG field. Original field will remain of the BIT type and will be returned. This happens when we convert DISTINCT to
GROUP BY.

The solution is to take into account the number of such hidden fields that would be added to the field
JOIN::all_fields list while calculating the size of the ref_pointer_array.
2018-05-16 11:40:11 +05:30
Varun Gupta
16319409bf MDEV-15853: Assertion `tab->filesort_result == 0' failed
The issue here is that the window function execution is not called for the correct join tab, when we have GROUP BY
where we create extra temporary tables then we need to call window function execution for the last join tab. For doing
so the current code does not take into account the JOIN::aggr_tables.
Fixed by introducing a new function JOIN::total_join_tab_cnt that takes in account the temporary tables also.
2018-05-11 03:23:17 +05:30
Sergei Golubchik
9b1824dcd2 Merge branch '10.1' into 10.2 2018-05-10 13:01:42 +02:00
Sergei Golubchik
9989c26bc9 Merge branch '10.0' into 10.1 2018-05-05 14:01:59 +02:00
Sergei Golubchik
c4499a0391 Merge branch '5.5' into 10.0 2018-04-29 00:38:10 +02:00
Igor Babaev
eb057dce20 MDEV-15035 Wrong results when calling a stored procedure
multiple times with different arguments.

If the ON expression of an outer join is an OR formula with one
of the disjunct being a constant formula then the expression
cannot be null-rejected if the constant formula is true. Otherwise
it can be null-rejected and if so the outer join can be converted
into inner join. This optimization was added in the patch for
mdev-4817. Yet the code had a defect: if the query was used in
a stored procedure with parameters and the constant item contained
some of them then the value of this constant item depended on the
values of the parameters. With some parameters it may be true,
for others not. The validity of conversion to inner join is checked
only once and it happens only for the first call of procedure.
So if the  parameters in the first call allowed the conversion it
was done and next calls used the transformed query though there
could be calls whose parameters made the conversion invalid.

Fixed by cheking whether the constant disjunct in the ON expression
originally contained an SP parameter. If so the expression is not
considered as null-rejected. For this check a new item's attribute
was intruduced: Item::with_param. It is calculated for each item
by fix fields() functions.
Also moved the call of optimize_constant_subqueries() in
JOIN::optimize after the call of simplify_joins(). The reason
for this is that after the optimization introduced by the patch
for mdev-4817 simplify_joins() can use the results of execution
of non-expensive constant subqueries and this is not valid.
2018-04-25 09:22:06 -07:00
Igor Babaev
f033fbd9f2 Changed the test case for MDEV-15571
It has been done to demonstrate that the fix of this bug is good for 10.3
as well. The previous test case is not good for this purpose because
10.2 and 10.3 use different rules for determining the types of recursive
CTEs.
2018-04-24 12:39:41 -07:00
Marko Mäkelä
39a4985520 Remove most 'register' use in C++
Modern compilers (such as GCC 8) emit warnings that the
'register' keyword is deprecated and not valid C++17.

Let us remove most use of the 'register' keyword.
Code in 'extra/' is not touched.
2018-04-24 12:48:27 +03:00
Varun Gupta
e3dd9a95e5 MDEV-6736: Valgrind warnings 'Invalid read' in subselect_engine::calc_const_tables with SQ in WHERE and
HAVING, ORDER BY, materialization+semijoin

During cleanup a pointer to the materialised table that was freed was not set to NULL
2018-03-17 10:51:19 +05:30
Sergei Petrunia
28777046b4 MDEV-15245: Assertion `false' failed in myrocks::ha_rocksdb::position
Don't call handler->position() if the last call to read a row did
not succeed.
2018-03-11 16:43:36 +00:00
Sergei Golubchik
4771ae4b22 Merge branch 'github/10.1' into 10.2 2018-02-06 14:50:50 +01:00
Sergei Golubchik
d4df7bc9b1 Merge branch 'github/10.0' into 10.1 2018-02-02 10:09:44 +01:00
Oleksandr Byelkin
80d3eee072 MDEV-14857: problem with 10.2.11 server crashing when executing stored procedure
Counter for select numbering made stored with the statement (before was global)
So now it does have always accurate value which does not depend on
interruption of statement prepare by errors like lack of table in
a view definition.
2018-02-01 09:51:47 +01:00
Monty
204739df14 Fixed memory overrun in create_postjoin_aggr_table() 2018-01-26 15:04:20 +02:00
Vicențiu Ciorbaru
d833bb65d5 Merge remote-tracking branch '5.5' into 10.0 2018-01-24 12:29:31 +02:00
Oleksandr Byelkin
ba8d0fa700 MDEV-14786: Server crashes in Item_cond::transform on 2nd execution of SP querying from a view
MDEV-14957: JOIN::prepare gets unusable "conds" as argument

Do not touch merged derived (it is irreversible)

Fix first argument of in_optimizer for calls possible before fix_fields()
2018-01-23 13:42:41 +01:00
Vicențiu Ciorbaru
b20c3dc664 MDEV-14715: Assertion `!table || (!table->read_set... failed in Field_num::val_decimal
The assertion failure was caused by an incorrectly set read_set for
functions in the ORDER BY clause in part of a union, when we are using
a mergeable view and the order by clause can be skipped (removed).

An order by clause can be skipped if it's part of one part of the UNION as
the result set is not meaningful when multiple SELECT queries are UNIONed. The
server is aware of this optimization and tries to remove the order by
clause before JOIN::prepare. The problem is that we need to throw an
error when the ORDER BY clause contains invalid columns. To do this, we
attempt resolving the ORDER BY expressions, then subsequently drop them
if resolution succeeded. However, ORDER BY resolution had the side
effect of adding the expressions to the all_fields list, which is used
to construct temporary tables to store the result. We may be ignoring
the ORDER BY statement, but the tmp table still tried to compute the
values for the expressions, even if the columns are never used.

The assertion only shows itself if the order by clause contains members
which were not previously in the select list, and are part of a
function.

There is an additional question as to why this only manifests when using
VIEWS and not when using a regular table. The difference lies with the
"reset" of the read_set for the temporary table during
SELECT_LEX::update_used_tables() in JOIN::optimize(). The changes
introduced in fdf789a7ea cleared the
read_set when a mergeable view is encountered in the TABLE_LIST
defintion.

Upon initial order_list resolution, the table's read_set is updated
correctly. JOIN::optimize() will only reset the read_set if it
encounters a VIEW. Since we no longer have ORDER BY clause in
JOIN::optimize() we never get to correctly update the read_set again.

Other relevant commit by Timour, which first introduced the order
resolution when we "can_skip_sort_order":
883af99e7d

Solution:
Don't add the resolved ORDER BY elements to all_fields. We only resolve
them to check if an error should be returned for the query. Ignore them
completely otherwise.
2018-01-22 15:39:42 +02:00
Vicențiu Ciorbaru
6d826e3d7e Remove commented out code post merge fix in 2011 2018-01-22 15:39:42 +02:00
Sergei Petrunia
9b4dfdaa5a MDEV-13352: Server crashes in st_join_table::remove_duplicates
join_tab->distinct=true means "Before doing record read with this
join_tab, call join_tab->remove_duplicates() to eliminate duplicates".
remove_duplicates() assumes that
- there is a temporary table $T with rows that are to be de-duplicated
- there is a previous join_tab (e.g. with join_tab->fields) which was
used to populate the temp.table $T.

When the query has "Impossible WHERE" and window function, then the above
conditions are not met (but we still might need a window function
computation step when the query has implicit grouping).

The fix is to not add remove_duplicates step if the select execution is
degenerate (and we'll have at most one row in the output anyway).
2018-01-22 13:44:31 +03:00
Sergei Golubchik
22ae3843db Correct TRASH() macro usage
TRASH was mapped to TRASH_FREE and was supposed to be used for memory
that should not be accessed anymore, while TRASH_ALLOC() is to be
used for uninitialized but to-be-used memory.

But sometimes TRASH() was used in the latter sense.

Remove TRASH() macro, always use explicit TRASH_ALLOC() or TRASH_FREE().
2018-01-22 11:39:54 +01:00
Varun Gupta
a7a4519a40 MDEV-14241: Server crash in key_copy / get_matching_chain_by_join_key or valgrind warnings
In this case we were using the optimization derived_with_keys but we could not create a key
because the length of the key was greater than the max allowed(MI_MAX_KEY_LENGTH).
To do the join we needed to create a hash join key instead, but in the explain output it
showed that we were still referring to derived keys which were created but not used.
2018-01-19 13:29:31 +05:30
Igor Babaev
4f96b401d9 Fixed mdev-14960 [ERROR] mysqld got signal 11 with join_buffer and join_cache
In the function JOIN::shrink_join_buffers the iteration over joined
tables was organized in a wrong way. This could cause a crash if
the optimizer chose to materialize a semi-join that used join caches
for which the sizes must be adjusted.
2018-01-18 09:57:25 -08:00
Sergei Golubchik
2d52d3c1bf Merge branch 'mysql/5.5' into 5.5 2018-01-18 17:54:48 +01:00
Sergei Golubchik
0d59b1db83 cleanup 2018-01-18 17:50:34 +01:00
Sergei Golubchik
444587d8a3 BIT field woes
* get_rec_bits() was always reading two bytes, even if the
  bit field contained only of one byte
* In various places the code used field->pack_length() bytes
  starting from field->ptr, while it should be field->pack_length_in_rec()
* Field_bit::key_cmp and Field_bit::cmp_max passed field_length as
  an argument to memcmp(), but field_length is the number of bits!
2018-01-16 23:29:48 +01:00
Igor Babaev
6267be460a Fixed mdev-14911: zero_date is considered as NULL, depending on
optimizer_switch

For DATE and DATETIME columns defined as NOT NULL,
"date_notnull IS NULL" has to be modified to:
"date_notnull IS NULL OR date_notnull == 0"
if date_notnull is from an inner table of outer join);
"date_notnull == 0" - otherwise.

This must hold for such columns of mergeable views and derived
tables as well. So far the code did the above re-writing only
for columns of base tables and temporary tables.
2018-01-15 11:19:14 -08:00
Igor Babaev
abc123391f Fixed mdev-6706 Wrong result (missing rows)
with joins, SQ, ORDER BY, semijoin=on

A bug in get_sort_by_table() could mislead the function
setup_semijoin_dups_elimination(). As a result the optimizer
could produce invalid execution plans for queries with ORDER BY
and subquery predicates that could be converted to semi-joins.
2018-01-12 13:14:27 -08:00
Sachin Setiya
73cf630ffc Fix Compile Error while using Flag '-DUSE_ARIA_FOR_TMP_TABLES:BOOL=OFF' 2018-01-07 00:33:17 +05:30
Sergei Petrunia
c584a496d7 Fix out-of-date comments. 2018-01-04 14:04:52 +03:00
Vicențiu Ciorbaru
6c4cf79d94 MDEV-13683: crash in Item_window_func::update_used_tables
Window definitions are resolved during fix fields. Updating used tables
for window functions must be done after all window functions have had a
chance to be resolved.

There was an additional problem with the implementation: expressions that
contained window functions never updated the expression's used tables.
To fix both these issues, make sure to call "update_used_tables" on all
items that contain window functions after we have passed through all
items.
2017-12-28 20:04:23 +02:00
Igor Babaev
dcbf2823c7 Fixed MDEV-13994 Bad join results with orderby_uses_equalities=on.
This patch effectively blocks the optimization that uses multiple
equalities for ORDER BY to remove tmp table in the case when
the first table happens to be the result of materialization of
a semi-join nest. Currently there is no code at the execution level
that would support the optimization in this case.
2017-11-10 14:01:29 -08:00
Igor Babaev
beac522b55 Fixed mdev-14093 Wrong result upon JOIN with INDEX with no rows
in joined table + GROUP BY + GROUP_CONCAT + HAVING + ORDER BY
[by field from HAVING] + 1 row expected

The fix is actually a port of the fix for bug #17055185 from
mysql code line (see commit f289aeeef0743508ff87211084453b3b88a6d017
by Mithun C Y into mysql-5.6). The test case for the bug #17055185
was also ported.
2017-11-02 15:57:13 -07:00
Marko Mäkelä
cbd0da66e4 Merge 10.1 into 10.2 2017-10-25 17:17:21 +03:00
Marko Mäkelä
db203d7471 Merge 10.0 into 10.1 2017-10-24 20:36:03 +03:00
Sergei Golubchik
e0a1c745ec Merge branch '10.1' into 10.2 2017-10-24 14:53:18 +02:00
Igor Babaev
acb336f75e MDEV-13607 MariaDB crash in fix_semijoin_strategies_for_picked_join_order
An overflow of the double variable storing the estimate of the
number of rows in a partial join could trigger an assertion
failure during the optimization stage.
2017-10-23 15:33:13 -07:00
Sergei Golubchik
9d2e2d7533 Merge branch '10.0' into 10.1 2017-10-22 13:03:41 +02:00
Sreeharsha Ramanavarapu
84c32cdbe7 Bug #26867652: INCORRECT BEHAVIOR WITH PREPARE STATEMENT
AND PARAM IN ORDER BY

Issue:
------
This issue can occur when the ORDER BY list refers to a
column that contains a parameter in the select list.

Solution:
---------
In JOIN::update_depend_map and get_sort_by_table, the
ORDER BY list's used_tables isn't checked for parameters.
This can result in incorrect behavior.

This is a partial backport of Roy's
2017-10-19 10:19:36 +05:30
Sergei Golubchik
da4503e956 Merge branch '5.5' into 10.0 2017-10-18 15:14:39 +02:00
Oleksandr Byelkin
235b68299b MDEV-9619: Assertion `null_ref_table' failed in virtual table_map Item_direct_view_ref::used_tables() const on 2nd execution of PS
Refer left expression indirectly in case it changes from execution to execution.
2017-10-13 19:32:38 +02:00
Igor Babaev
2bab29ebba Fixed the bug mdev-13135.
For each SELECT the list sj_nests is built by the
function simplify_joins() when scanning different
join nests. This function may be called several
times for the same join nest. That's why before
adding a new member to sj_nests it is necessary
to check if it's already in the list.
The code of simplify_joins() lacked this check and
as a result it could cause memory overwright for
some queries.
2017-10-13 07:24:54 -07:00
Vladislav Vaintroub
dc93ce8dea Windows : Fix truncation warnings in sql/ 2017-10-10 06:19:50 +00:00
Vladislav Vaintroub
7354dc6773 MDEV-13384 - misc Windows warnings fixed 2017-09-28 17:20:46 +00:00
Vladislav Vaintroub
eba44874ca MDEV-13844 : Fix Windows warnings. Fix DBUG_PRINT.
- Fix win64 pointer truncation warnings
(usually coming from misusing 0x%lx and long cast in DBUG)

- Also fix printf-format warnings

Make the above mentioned warnings fatal.

- fix pthread_join on Windows to set return value.
2017-09-28 17:20:46 +00:00
Sergei Golubchik
55c5448ab7 MDEV-13751 Interrupted SELECT fails with 1030: 'Got error 1 "Operation not permitted" from storage engine MyISAM'
quick select returns 1, not proper HA_ERR_xxx error code,
so don't send it to handler::print_error().
2017-09-18 10:12:23 +02:00
Sergei Golubchik
cb1e76e4de Merge branch '10.1' into 10.2 2017-08-17 11:38:34 +02:00
Igor Babaev
a28152aafc Fixed the bug mdev-13346.
The bug was caused by a defect of the patch for the bug 11081.
The patch was actually a port of the fix this bug from the mysql
code line. Later a correction of this fix was added to the
mysql code. Here's the comment this correction was provided with:

  Bug#16499751: Opening cursor on SELECT in stored procedure causes segfault
  This is a regression from the fix of bug#14740889.
  The fix started using another set of expressions as the source for
  the temporary table used for the materialized cursor. However,
  JOIN::make_tmp_tables_info() calls setup_copy_fields() which creates
  an Item_copy wrapper object on top of the function being selected.
  The Item_copy objects were not properly handled by create_tmp_table -
  they were simply ignored. This patch creates temporary table fields
  based on the underlying item of the Item_copy objects.

The test case for the bug 13346 was taken from mdev-13380.
2017-08-15 16:20:48 -07:00
Sergei Petrunia
0b30ce4f31 MDEV-13374: Server crashes in first_linear_tab / st_select_lex::set_explain_type
- Support first_linear_tab() traversal for degenerate joins
2017-08-07 16:04:38 +03:00
Monty
74543698a7 MDEV-13179 main.errors fails with wrong errno
The problem was that the introduction of max-thread-mem-used can cause
an allocation error very early, even before mysql_parse() is called.
As mysql_parse() calls thd->reset_for_next_command(), which called
clear_error(), the error number was lost.

Fixed by adding an option to have unique messages for each KILL
signal and change max-thread-mem-used to use this new feature.
This removes a lot of problems with the original approach, where
one could get errors signaled silenty almost any time.

ixed by moving clear_error() from reset_for_next_command() to
do_command(), before any memory allocation for the thread.

Related changes:
- reset_for_next_command() now have an optional parameter if we should
  call clear_error() or not. By default it's called, but not anymore from
  dispatch_command() which was the original problem.
- Added optional paramater to clear_error() to force calling of
  reset_diagnostics_area(). Before clear_error() only called
  reset_diagnostics_area() if there was no error, so we normally
  called reset_diagnostics_area() twice.
- This change removed several duplicated calls to clear_error()
  when starting a query.
- Reset max_mem_used on COM_QUIT, to protect against kill during
  quit.
- Use fatal_error() instead of setting is_fatal_error (cleanup)
- Set fatal_error if max_thead_mem_used is signaled.
  (Same logic we use for other places where we are out of resources)
2017-08-07 03:48:58 +03:00
Sergei Petrunia
17fc288b30 MDEV-13352: Server crashes in st_join_table::remove_duplicates
Do not run the window function computation step when the select
produces no rows (zero_result_cause!=NULL).
This may cause reads from uninitialized memory.

We still need to run the window function computation step when
the output includes just one row  (for example
SELECT MAX(col), RANK() OVER (...) FROM t1 WHERE 1=0).

This fix also resolves an issue with queries with window functions
producing an output row where should be none, like in
SELECT ROW_NUMBER() FROM t1 WHERE 1=0.

Updated a few test results in the existing tests to reflect this.
2017-07-21 13:53:58 +03:00