1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-24 19:42:23 +03:00
Commit Graph

136 Commits

Author SHA1 Message Date
3b6dadb5eb Merge 10.1 into 10.2 2020-08-10 17:57:14 +03:00
ab578bdf45 MDEV-9513: Assertion `join->group_list || !join->is_in_subquery()' failed in create_sort_index
Removing the ORDER BY clause from the UNION when UNION is inside an IN/ALL/ANY/EXISTS subquery.
The rewrites are done for subqueries but this rewrite is not done for the fake_select of
the UNION.
2020-08-06 10:55:03 +05:30
1e31d74833 MDEV-17066: Bytes lost or Assertion `status_var.local_memory_used == 0 after DELETE with subquery with ROLLUP
The issue here is when records are read from the temporary file
(filesort result in this case) via a cache(rr_from_cache).
The cache is initialized with init_rr_cache.
For correlated subquery the cache allocation is happening at each execution
of the subquery but the deallocation happens only once and that was
when the query execution was done.

So generally for subqueries we do two types of cleanup

1) Full cleanup: we should free all resources of the query(like temp tables).
   This is done generally when the query execution is complete or the subquery
   re-execution is not needed (case with uncorrelated subquery)

2) Partial cleanup: Minor cleanup that is required if
   the subquery needs recalculation. This is done for all the structures that
   need to be allocated for each execution (example SORT_INFO for filesort
   is allocated for each execution of the correlated subquery).

The fix here would be free the cache used by rr_from_cache in the partial
cleanup phase.
2020-08-05 11:28:32 +05:30
ef7cb0a0b5 Merge branch '10.1' into 10.2 2020-08-02 11:05:29 +02:00
62d73df6b2 MDEV-19232: Floating point precision / value comparison problem
The issue occurs when the subquery_cache is enabled.
When there is a cache miss the division was leading to a value with scale 9.
In the case of cache hit the value returned was of scale 9 and due to the different
values for the scales the where condition evaluated to FALSE, hence the output
was incomplete.

To fix this problem we need to round up the decimal to the limit mentioned in
Item::decimals. This would make sure the values are compared with the same
scale.
2020-07-22 14:44:25 +05:30
ea2bc974dc Merge 10.1 into 10.2 2020-07-01 12:03:55 +03:00
fbfb5b5f68 MDEV-22852: SIGSEGV in sortlength (optimized builds)
The issue here is for a DEPENDENT subquery that has an aggregate function in the ORDER BY clause,
is wrapped inside an Item_aggregate_ref. For computation of ORDER BY we need to refer to the
temp table field corresponding to this item. But in the function make_sortorder, we were
explicitly casting Item_aggrgate_ref to Item_sum, which leads to us not getting the temp
table field corresponding to the item.
2020-07-01 11:39:22 +05:30
37cb7a0071 MDEV-17606: Query returns wrong results (while using CHARACTER SET utf8)
The issue here was that the left expr and right expr of the ANY subquery
had different character sets, so we were converting the left expr to utf8 character set.
So when this conversion was happening we were actually converting the item inside the cache,
it looked like <cache>(convert(t1.l1 using utf8)), which is incorrect.
To fix this problem we are going to store the reference of the left expr and convert that
to utf8 character set, it would look like convert(<cache>(`test`.`t1`.`l1`) using utf8)
2020-06-27 12:55:55 +05:30
fc0960aa96 Merge 10.1 into 10.2 2020-05-15 22:43:33 +03:00
efd68f5e31 MDEV-22498: SIGSEGV in Bitmap<64u>::merge on SELECT
For the case when the optimizer does the IN-EXISTS transformation,
the equality condition is injected in the WHERE OR HAVING clause of
the subquery. If the select list of the subquery has a reference to
the parent select make sure to use the reference and not the original
item.
2020-05-14 23:24:10 +05:30
9cba6c5aa3 Updated mtr files to support different compiled in options
This allows one to run the test suite even if any of the following
options are changed:
- character-set-server
- collation-server
- join-cache-level
- log-basename
- max-allowed-packet
- optimizer-switch
- query-cache-size and query-cache-type
- skip-name-resolve
- table-definition-cache
- table-open-cache
- Some innodb options
etc

Changes:
- Don't print out the value of system variables as one can't depend on
  them to being constants.
- Don't set global variables to 'default' as the default may not
  be the same as the test was started with if there was an additional
  option file. Instead save original value and reset it at end of test.
- Test that depends on the latin1 character set should include
  default_charset.inc or set the character set to latin1
- Test that depends on the original optimizer switch, should include
  default_optimizer_switch.inc
- Test that depends on the value of a specific system variable should
  set it in the test (like optimizer_use_condition_selectivity)
- Split subselect3.test into subselect3.test and subselect3.inc to
  make it easier to set and reset system variables.
- Added .opt files for test that required specfic options that could
  be changed by external configuration files.
- Fixed result files in rockdsb & tokudb that had not been updated for
  a while.
2019-09-01 19:17:35 +03:00
9c34a4124d Merge 10.0 into 10.1 2018-04-24 09:26:40 +03:00
587568b72a Merge branch '5.5' into 10.0 2018-04-20 14:33:24 +02:00
5e61e1716e MDEV-14515 ifnull result depends on number of rows in joined table
Any expensive WHERE condition for a table-less query with
implicit aggregation was lost. As a result the used aggregate
functions were calculated over a non-empty set of rows even
in the case when the condition was false.
2018-04-16 16:59:19 -07:00
febe1e8503 Merge branch '10.0' into 10.1 2018-03-23 17:40:53 +01:00
a2e47f8c41 Merge branch '5.5' into 10.0 2018-03-23 11:44:29 +01:00
2dd4e50d5f MDEV-15555: select from DUAL where false yielding wrong result when in a IN
For the query having an IN subquery with no tables, we were converting the subquery with an expression between
the left part and the select list of the subquery . This can give incorrect results when we have a condition
in the subquery with a dual table (as this is treated as a no table).

The fix is that we don't do this conversion when we have conds in the subquery with a dual table.
2018-03-21 09:38:56 +02:00
09a2107b1b Merge branch '10.0' into 10.1 2017-03-21 19:20:44 +01:00
0d622bed4f Merge branch '5.5' into 10.0 2017-03-21 11:35:50 +01:00
adbe1c5fe9 MDEV-6486: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))'
failed with SELECT SQ, TEXT field

The functon find_all_keys does call Item_subselect::walk, which calls walk() for the subquery
The issue is that when a field is represented by Item_outer_ref(Item_direct_ref(Item_copy_string( ...))).
Item_copy_string does have a pointer to an Item_field in Item_copy::item but does not implement Item::walk method, so we are not
able to set the bitmap for that field. This is the reason why the assert fails.

Fixed by adding the walk method to Item_copy class.
2017-03-14 17:31:29 +05:30
ad0c218a44 Merge 10.0 into 10.1
Also, implement MDEV-11027 a little differently from 5.5 and 10.0:

recv_apply_hashed_log_recs(): Change the return type back to void
(DB_SUCCESS was always returned).

Report progress also via systemd using sd_notifyf().
2017-03-09 08:53:08 +02:00
47396ddea9 Merge 5.5 into 10.0
Also, implement MDEV-11027 a little differently from 5.5:

recv_sys_t::report(ib_time_t): Determine whether progress should
be reported.

recv_apply_hashed_log_recs(): Rename the parameter to last_batch.
2017-03-08 11:40:43 +02:00
43903745e5 MDEV-11078: NULL NOT IN (non-empty subquery) should never return results
Disabling the cond guards during the creation of Tricond Item for
constant and NULL left expression items
2017-03-05 10:58:05 +05:30
213fc700b6 MDEV-10232: Scalar result of subquery changes after adding an outer select stmt
In a subquery, we don't have to maintain order
Added a fix such that order is considered when there is a limit clause.
2017-01-21 00:56:33 +05:30
e9aed131ea Merge remote-tracking branch 'origin/5.5' into 10.0 2017-01-06 17:09:59 +02:00
268bb69bea MDEV-7691: Assertion `outer_context || !*from_field || *from_field == not_found_field' ...
The bug occurred when a subquery
- has a reference to outside, to grand-parent query or further up
- is converted to a semi-join (i.e. merged into its parent).

Then the reference to outside had form Item_ref(Item_field(...)).
- Conversion to semi-join would call item->fix_after_pullout() for the
  outside reference.
- Item_ref::fix_after_pullout would call Item_field->fix_after_pullout
- The Item_field would construct a new Name_resolution_context object
  This process ignored the fact that the Item_field does not belong to
  any of the subselects being flattened.
The result was crash in the next call to Item_field::fix_fields(), where
we would try to use an invalid Name_resolution_context object.

Fixed by not creating Name_resolution_context object if the Item_field's
context does not belong to the subselect(s) that were flattened.
2016-12-19 17:57:43 +03:00
10740939eb 5.5 merge 2014-03-26 22:25:38 +01:00
5d8c15228e 5.3-merge 2014-03-16 19:21:37 +01:00
1f2ef57403 Fixed bug mdev-5686.
The calls of the function remove_eq_conds() may change the and/or structure
of the where conditions. So JOIN::equal_cond should be updated for non-recursive
calls of remove_eq_conds().
2014-03-06 13:56:34 -08:00
0dc23679c8 10.0-base merge 2014-02-26 15:28:07 +01:00
f17079fa7e Merge 5.3->5.5 2014-02-10 17:00:51 -08:00
5b441013e1 Fixed bug mdev-5468.
The field JOIN::select_lex->where should be updated after the call
of remove_eq_conds() in the function make_join_statistics(). This
matters for subselects.
2014-02-05 17:47:38 -08:00
d28d3ba40d 10.0-base merge 2013-12-16 13:02:21 +01:00
d34e46795e Merge 5.3->5.5 2013-11-21 21:40:43 -08:00
c0f31dc9f3 Another attempt to fix bug mdev-5103.
The earlier pushed fix for the bug was incomplete. It did not remove
the main cause of the problem: the function remove_eq_conds()
removed always true multiple equalities from any conjunct, but did not
adjust the list of them stored in Item_cond_and::cond_equal.current_level.

Simplified the test case for the bug and moved it to another test file.

The fix triggered changes in EXPLAIN EXTENDED for some queries.
2013-11-21 15:19:25 -08:00
fcf87600a2 MDEV-4865 Change related to --log option/variable was merged partially
Complete the merge of magne.mahre@oracle.com-20101102115354-vxcaxminmzglzalk
(WL#5185 Remove deprecated 5.1 features)
2013-08-13 13:35:36 +02:00
599a1384af Fix for MDEV-4144
Analysis:
The reason for the inefficent plan was that Item_subselect::is_expensive()
didn't detect the special case when a subquery was optimized, but had no
join plan because it either has no table, or its tables have been optimized
away, or the optimizer detected that the result set is empty.
  
Solution:
Identify the special cases above in the Item_subselect::is_expensive(),
and consider such degenerate subqueries inexpensive.
2013-03-29 17:53:21 +02:00
32151409c1 Merge 5.3->5.5 2013-01-23 15:18:05 -08:00
2255132f20 MDEV-4056 fix.
The problem was that maybe_null of Item_row and its componetes was unsynced after update_used_tables() (and so pushed_cond_guards was not initialized but then requested).

Fix  updates Item_row::maybe_null on update_used_tables().
2013-01-16 21:07:26 +02:00
aca8e7ed6b 5.3 merge 2013-01-15 19:07:46 +01:00
e99aa91e90 MDEV-3928: Assertion `example' failed in Item_cache::is_expensive_processor with a 2-level IN subquery
Analysis:
The following call stack shows that it is possible to set Item_cache::value_cached, and the relevant value
without setting Item_cache::example.

#0 Item_cache_temporal::store_packed at item.cc:8395
#1 get_datetime_value at item_cmpfunc.cc:915
#2 resolve_const_item at item.cc:7987
#3 propagate_cond_constants at sql_select.cc:12264
#4 propagate_cond_constants at sql_select.cc:12227
#5 optimize_cond at sql_select.cc:13026
#6 JOIN::optimize at sql_select.cc:1016
#7 st_select_lex::optimize_unflattened_subqueries at sql_lex.cc:3161
#8 JOIN::optimize_unflattened_subqueries at opt_subselect.cc:4880
#9 JOIN::optimize at sql_select.cc:1554

The fix is to set Item_cache_temporal::example even when the value is
set directly by Item_cache_temporal::store_packed. This makes the
Item_cache_temporal object consistent.
2012-12-19 15:56:57 +02:00
a8bad7d900 MDEV-3902 Assertion `record_length == m_record_length' failed at Filesort_buffer::alloc_sort_buffer
This bug is a duplicate of mdev-3899 so adding a test case only.
2012-12-21 11:18:29 +02:00
1b2692d0e9 MDEV-3899 Valgrind warnings (blocks are definitely lost) in filesort on IN subquery with SUM and DISTINCT
Analysys:
In the beginning of JOIN::cleanup there is code that is supposed to
free all filesort buffers. The code assumes that the table being sorted
is the first non-constant table. To get this table it calls:
first_top_level_tab(this, WITHOUT_CONST_TABLES)
  
However, first_top_level_tab() instead returned the wrong table - the first
one in the plan, instead of the first non-constant table. There is no other
place outside filesort() where sort buffers may be freed. As a result, the
sort buffer was not freed, and there was a memory leak.
  
Solution:
Change first_top_level_tab(), to test for WITH_CONST_TABLES instead of
WITHOUT_CONST_TABLES.
2012-12-20 22:38:40 +02:00
caf31114c8 Merged the fix for bug lp:1009187, mdev-373 2012-09-18 13:42:06 +03:00
0bc89929ef - Merged the fix for bug lp:1009187, mdev-373.
- Performed some refactoring and simplification that was enabled and required by the merge.
2012-09-17 11:13:46 +03:00
b917fb63a6 Fix bug lp:1009187, mdev-373, mysql bug#58628
Analysis:
The queries in question use the [unique | index]_subquery execution methods.
These methods reuse the ref keys constructed by create_ref_for_key(). The
way create_ref_for_key() works is that it doesn't store in ref.key_copy[]
store_key elements that represent constants. In particular it doesn't store
the store_key for NULL constants.

The execution of [unique | index]_subquery calls
subselect_uniquesubquery_engine::copy_ref_key, which in addition to copy
the left IN argument into a index lookup key, is supposed to detect if
the left IN argument contains NULLs. Since the store_key for the NULL
constant is not copied into the key array, the null is not detected, and
execution erroneously proceeds as if it should look for a complete match.

Solution:
The solution (unlike MySQL) is to reuse already computed information about
NULL presence. Item_in_optimizer::val_int already finds out if the left IN
operand contains NULLs. The fix propagates this to the execution methods
subselect_[unique | index]subquery_engine::exec so it knows if there were
NULL values independent of the presence of keys.

In addition the patch siplifies copy_ref_key() and the logic that hanldes
the case of NULLs in the left IN operand.
2012-09-14 11:26:01 +03:00
0b93b444b6 Merged the fix for bug lp:944706, mdev-193 2012-06-19 15:06:45 +03:00
28f2c5641d 5.3->5.5 merge 2012-06-18 16:50:16 +04:00
88d3d853f4 Fix bug lp:1008773
Analysis:
Queries with implicit grouping (there is aggregate, but no group by)
follow some non-obvious semantics in the case of empty result set.
Aggregate functions produce some special "natural" value depending on
the function. For instance MIN/MAX return NULL, COUNT returns 0.

The complexity comes from non-aggregate expressions in the select list.
If the non-aggregate expression is a constant, it can be computed, so
we should return its value, however if the expression is non-constant,
and depends on columns from the empty result set, then the only meaningful
value is NULL.

The cause of the wrong result was that for subqueries the optimizer didn't
make a difference between constant and non-constant ones in the case of
empty result for implicit grouping.

Solution:
In all implementations of Item_subselect::no_rows_in_result() check if the
subquery predicate is constant. If it is constant, do not set it to the
default value for implicit grouping, instead let it be evaluated.
2012-06-14 17:03:09 +03:00
c2677de7ac Merge the fix for lp:944706, mdev-193 2012-06-06 22:26:40 +03:00