summaryrefslogtreecommitdiff
path: root/sql/sql_select.cc
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.2 into 10.3Marko Mäkelä2020-11-021-3/+3
|\
| * MDEV-22387: Do not violate __attribute__((nonnull))Marko Mäkelä2020-11-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | This follows up commit commit 94a520ddbe39ae97de1135d98699cf2674e6b77e and commit 7c5519c12d46ead947d341cbdcbb6fbbe4d4fe1b. After these changes, the default test suites on a cmake -DWITH_UBSAN=ON build no longer fail due to passing null pointers as parameters that are declared to never be null, but plenty of other runtime errors remain.
* | MDEV-21201 No records produced in information_schema query, depending on ↵Sergei Golubchik2020-10-231-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | projection Reimplement MDEV-14275 Improving memory utilization for information schema Postpone temp table instantiation until after setup_fields(). Replace all unused (not marked in read_set) columns in an I_S table with CHAR(0). This can drastically reduce the footprint of a MEMORY table (a TABLE_CATALOG alone is 1538 bytes per row). This does not change the engine. If the table was decided to be Aria (because of, say, blobs) then after optimization it'll stay Aria even if all blobs were removed. Note 1: when transforming table structure, share->blob_fields is preserved, otherwise Aria might switch from DYNAMIC to STATIC row format and expect a special field for a deleted mark, which create_tmp_tabe didn't provide. Note 2: optimizer was doing handler::info() (to know the number of rows) before the temp table is populated. That didn't make much sense. Now it's done before the table is even instantiated. Preserve the old behavior and report 0 rows. This reverts e2664ee8362 and a8458a2345e
* | cleanup: use my_multi_malloc(), etcSergei Golubchik2020-10-231-12/+6
| |
* | Merge 10.2 into 10.3Marko Mäkelä2020-10-221-0/+3
|\ \ | |/
| * Merge 10.1 into 10.2Marko Mäkelä2020-10-211-0/+3
| |\
| | * MDEV-17729: Assertion `! is_set() || m_can_overwrite_status' failed inRucha Deodhar2020-10-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Diagnostics_area::set_error_status Analysis: When strict mode is enabled, all warnings are converted to errors including those which do not occur because of bad data. Fix: Query should not be aborted when we have warning because limit to examine rows was reached because it doesn't happen due to bad data. So thd->abort_on_warning should be false.
* | | MDEV-23779 Error upon querying the view, that selecting from versioned table ↵Aleksey Midenkov2020-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with partitions PARTITION clause in SELECT means query is non-versioned (see WITH_PARTITION_STORAGE_ENGINE in vers_setup_conds()). vers_setup_conds() expands such query to SYSTEM_TIME_ALL which is then added to VIEW specification. When VIEW is queried both clauses PARTITION and FOR SYSTEM_TIME ALL lead to ER_VERS_QUERY_IN_PARTITION (same place WITH_PARTITION_STORAGE_ENGINE). Fix removes FOR SYSTEM_TIME ALL from VIEW by accessing original SYSTEM_TIME clause: the one specified in parser. As a side-effect EXPLAIN SELECT displays SYSTEM_TIME specified in SELECT which is user-friendly.
* | | MDEV-23799 CREATE .. SELECT wrong result on join versioned tableAleksey Midenkov2020-10-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For join to work correctly versioning condition must be added to table on_expr. Without that JOIN_CACHE gets expression (1) trigcond(xtitle.row_end = TIMESTAMP'2038-01-19 06:14:07.999999') and trigcond(xtitle.elementId = x.`id` and xtitle.pkey = 'title') instead of (2) trigcond(xtitle.elementId = x.`id` and xtitle.pkey = 'title') for join_null_complements(). It is NULL-row of xtitle for complementing the join and the above comparisons of course FALSE, but trigcond (Item_func_trig_cond) makes them TRUE via its trig_var property which is bound to some boolean properties of JOIN_TAB. Expression (2) evaluated to TRUE because its trig_var is bound to first_inner_tab->not_null_compl. The expression (1) does not evaluate correctly because row_end comparison's trig_var is bound to first_inner->found earlier. As a result JOIN_CACHE::check_match() skipped the row for join_null_complements(). When we add versioning condition to table's on_expr the optimizer in make_join_select() distributes conditions differently. tmp_cond inherits on_expr value and in Good case it is full expression xgender.elementId = x.`id` and xgender.pkey = 'gender' and xgender.row_end = TIMESTAMP'2038-01-19 06:14:07.999999' while in Bad case it is only xgender.elementId = x.`id` and xgender.pkey = 'gender'. Later in Good row_end condition is optimized out and we get one trigcond in form of (2).
* | | Merge 10.2 into 10.3Marko Mäkelä2020-09-031-0/+3
|\ \ \ | |/ /
| * | Merge 10.1 into 10.2Marko Mäkelä2020-09-011-0/+3
| |\ \ | | |/ | | | | | | This also fixes MDEV-20464.
| | * MDEV-23596: Assertion `tab->ref.use_count' failed in join_read_key_unlock_rowbb-10.1-varunVarun Gupta2020-08-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | The issue here was that the query was using ORDER BY LIMIT optimzation where the access method was changed from EQ_REF access to an index scan (index that would resolve the ORDER BY clause). But the parameter READ_RECORD::unlock_row was not reset to rr_unlock_row, which is used when the access method is not EQ_REF access.
* | | Merge 10.2 into 10.3Marko Mäkelä2020-08-101-18/+35
|\ \ \ | |/ /
| * | MDEV-17066: Bytes lost or Assertion `status_var.local_memory_used == 0 after ↵Varun Gupta2020-08-051-18/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-08-031-1/+1
|\ \ \ | |/ /
| * | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-08-021-1/+1
| |\ \ | | |/
| | * MDEV-23221: A subquery causes crashSergei Petrunia2020-07-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Fix the crash: IN-to-EXISTS rewrite causes an error (and so JOIN::optimize() fails with an error, too), don't call update_used_tables(). Terminate the query execution instead. * Fix the cause of the error in the IN-to-EXISTS rewrite: don't do the rewrite if doing it will cause an error of this kind: This version of MariaDB doesn't yet support 'SUBQUERY in ROW in left expression of IN/ALL/ANY' * Fix another issue exposed by this testcase: JOIN::setup_subquery_caches() may be invoked before any select has saved its query plan, and will crash because none of the SELECTs has called create_explain_query_if_not_exists() to create the Explain Data Structure for this SELECT. TODO: When merging this to 10.2, remove the poorly-placed call to create_explain_query_if_not_exists made by fix for M_D_E_V-16153
| | * Revert "MDEV-22830: SQL_CALC_FOUND_ROWS not working properly for single ↵Oleksandr Byelkin2020-06-101-1/+1
| | | | | | | | | | | | | | | | | | SELECT for DUAL" This reverts commit 443391236d20cd0303fcc9957eb49a6aaf28316e.
| | * MDEV-22830: SQL_CALC_FOUND_ROWS not working properly for single SELECT for DUALrucha1742020-06-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In case of SELECT without tables which returns either 0 or 1 rows, JOIN::exec_inner() did not check if the flag representing SQL_CALC_FOUND_ROWS is set or not and send_records was direclty assigned 0. So SELECT FOUND_ROWS() was giving 0 in the output. Now it checks if the flag is set, if it is set send_record=1 else 0. 1 is the number of rows that could have been sent to the client if the SELECT query had SQL_CALC_FOUND_ROWS. It is 0 when no rows were sent because the SELECT query did not have SQL_CALC_FOUND_ROWS.
* | | Merge 10.2 into 10.3Marko Mäkelä2020-07-141-2/+17
|\ \ \ | |/ /
| * | MDEV-10120: Wrong result of UNION .. ORDER BY GROUP_CONCAT()Varun Gupta2020-07-101-1/+16
| | | | | | | | | | | | | | | Reject queries that have aggregate functions with UNION as these are not allowed by standard.
* | | Don't give errors for default value copy in create_tmp_tableMonty2020-07-031-0/+7
| | |
* | | Fixed bugs found by valgrindMonty2020-07-021-13/+31
| | | | | | | | | | | | | | | | | | | | | - Some of the bug fixes are backports from 10.5! - The fix in innobase/fil/fil0fil.cc is just a backport to get less error messages in mysqld.1.err when running with valgrind. - Renamed HAVE_valgrind_or_MSAN to HAVE_valgrind
* | | MDEV-22535 TABLE::initialize_quick_structures() takes 0.5% in oltp_read_onlyMonty2020-07-021-1/+1
| | | | | | | | | | | | | | | | | | | | | - Removed not needed bzero in void TABLE::initialize_quick_structures(). - Replaced bzero with TRASH_ALLOC() to have this change verfied with memory checkers - Added missing table->quick_keys.is_set in table_cond_selectivity()
* | | Merge 10.2 into 10.3Marko Mäkelä2020-07-021-0/+1
|\ \ \ | |/ /
| * | MDEV-22779: Crash: Prepared Statement with a '?' parameter inside a re-used CTESergei Petrunia2020-06-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a prepared statement parameter '?' is used in a CTE that is used multiple times, the following happens: - The CTE definition is re-parsed multiple times. - There are multiple Item_param objects referring to the same "?" in the original query. - Prepared_statement::param has a pointer to the first of them, the others are "clones". - When prepared statement parameter gets the value, it should be passed over to clones with param->sync_clones() call. This call is made in insert_params(), etc. It was not made in insert_params_with_log(). This would cause Item_param to not have any value which would confuse the query optimizer. Added the missing call.
* | | MDEV-22866: Crash in join optimizer with constant outer join nestSergei Petrunia2020-06-231-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting from 10.3, the optimizer is able to detect that entire outer join nests are constants (because of "Impossible ON") and remove them (see mark_join_nest_as_const) However, this was not properly accounted for in NESTED_JOIN structure and the way check_interleaving_with_nj() uses its n_tables member to check if the join prefix order is allowed. (The result was that the optimizer could conclude that no join prefix is allowed and fail an assertion)
* | | MDEV-22906 Disallow system_versioning_asof in DMLAleksey Midenkov2020-06-161-1/+4
| | | | | | | | | | | | | | | system_versioning_asof does not influence on multi-delete, multi-update, insert-select, replace-select.
* | | MDEV-22413 Server hangs upon UPDATE on a view reading from versioned ↵Aleksey Midenkov2020-05-281-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | partitioned table UPDATE gets access to history records because versioning conditions are not set for VIEW. This leads to endless loop of inserting history records when clustered index is rebuilt and ha_rnd_next() returns newly inserted history record. Return back original behavior of failing on write-locked table in historical query. 35b679b9 assumed that SELECT_LEX::lock_type influences anything, but actually at this point table is already locked. Original bug report was tempesta-tech/mariadb#102
* | | Merge 10.2 into 10.3Marko Mäkelä2020-05-251-4/+9
|\ \ \ | |/ /
| * | MDEV-22461: JOIN::make_aggr_tables_info(): Assertion `select_options & (1ULL ↵Varun Gupta2020-05-251-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | << 17)' failed. A temporary table is needed for window function computation but if only a NAMED WINDOW SPEC is used and there is no window function, then there is no need to create a temporary table as there is no stage to compute WINDOW FUNCTION
* | | MDEV-21995 Server crashes in Item_field::real_type_handler with table value ↵Alexander Barkov2020-05-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constructor 1. Code simplification: Item_default_value handled all these values: a. DEFAULT(field) b. DEFAULT c. IGNORE and had various conditions to distinguish (a) from (b) and from (c). Introducing a new abstract class Item_contextually_typed_value_specification, to handle (b) and (c), so the hierarchy now looks as follows: Item Item_result_field Item_ident Item_field Item_default_value - DEFAULT(field) Item_contextually_typed_value_specification Item_default_specification - DEFAULT Item_ignore_specification - IGNORE 2. Introducing a new virtual method is_evaluable_expression() to determine if an Item is: - a normal expression, so its val_xxx()/get_date() methods can be called - or a just an expression substitute, whose value methods cannot be called. 3. Disallowing Items that are not evalualble expressions in table value constructors.
* | | MDEV-17568: LATERAL DERIVED is not clearly visible in EXPLAIN FORMAT=JSONSergei Petrunia2020-05-061-0/+2
| | | | | | | | | | | | Make LATERAL DERIVED tables visible in EXPLAIN FORMAT=JSON output.
* | | MDEV-21480: Unique key using ref access though eq_ref access can be usedVarun Gupta2020-05-011-6/+15
| | | | | | | | | | | | | | | | | | For a unique key if all the keyparts are NOT NULL or the predicates involving the keyparts is NULL rejecting, then we can use EQ_REF access instead of ref access with the unique key
* | | Merge 10.2 into 10.3Marko Mäkelä2020-03-301-2/+6
|\ \ \ | |/ /
| * | MDEV-22019: Sig 11 in next_breadth_first_tab | max_sort_length setting + ↵Varun Gupta2020-03-301-2/+6
| | | | | | | | | | | | | | | | | | double GROUP BY leads to crash No need to create a temp table for aggregation if we have encountered some error.
* | | Merge 10.2 into 10.3Marko Mäkelä2020-03-131-1/+1
|\ \ \ | |/ /
| * | Merge 10.1 into 10.2Marko Mäkelä2020-03-131-1/+1
| |\ \ | | |/
| | * Fix compile warning:Sergei Petrunia2020-03-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | It was: implicit conversion from 'ha_rows' (aka 'unsigned long long') to 'double' changes value from 18446744073709551615 to 18446744073709551616 Follow what JOIN::get_examined_rows() does for similar code.
* | | MDEV-21383: Possible range plan is not used under certain conditionsbb-10.3-mdev21383Sergei Petrunia2020-01-241-1/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [Variant 2 of the fix: collect the attached conditions] Problem: make_join_select() has a section of code which starts with "We plan to scan all rows. Check again if we should use an index." the code in that section will [unnecessarily] re-run the range optimizer using this condition: condition_attached_to_current_table AND current_table's_ON_expr Note that the original invocation of range optimizer in make_join_statistics was done using the whole select's WHERE condition. Taking the whole select's WHERE condition and using multiple-equalities allowed the range optimizer to infer more range restrictions. The fix: - Do range optimization using a condition that is an AND of this table's condition and all of the previous tables' conditions. - Also, fix the range optimizer to prefer SEL_ARGs with type=KEY_RANGE over SEL_ARGS with type=MAYBE_KEY, regardless of the key part. Computing key_and( SEL_ARG(type=MAYBE_KEY key_part=1), SEL_ARG(type=KEY_RANGE, key_part=2) ) will now produce the SEL_ARG with type=KEY_RANGE.
* | | Merge 10.2 into 10.3Marko Mäkelä2020-01-181-1/+1
|\ \ \ | |/ /
| * | Fix a merge typoSergei Petrunia2020-01-171-1/+1
| | |
* | | Merge branch '10.2' into 10.3Sergei Petrunia2020-01-171-5/+8
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | # Conflicts: # mysql-test/suite/galera/r/MW-388.result # mysql-test/suite/galera/t/MW-388.test # mysql-test/suite/innodb/r/truncate_inject.result # mysql-test/suite/innodb/t/truncate_inject.test # mysql-test/suite/rpl/r/rpl_stop_slave.result # mysql-test/suite/rpl/t/rpl_stop_slave.test # sql/sp_head.cc # sql/sp_head.h # sql/sql_lex.cc # sql/sql_yacc.yy # storage/xtradb/buf/buf0dblwr.cc
| * | Merge branch '10.1' into 10.2Sergei Petrunia2020-01-171-5/+8
| |\ \ | | |/ | | | | | | | | | | | | | | | # Conflicts: # sql/sp_head.cc # sql/sql_select.cc # sql/sql_trigger.cc
| | * MDEV-21341: Fix UBSAN failures, part 8: fix error in ↵Sergei Petrunia2020-01-151-4/+8
| | | | | | | | | | | | | | | | | | | | | compare_fields_by_table_order Dont assign Item_field variables to point to Item_string objects (even if we don't make any dangerous calls for them).
* | | MDEV-21243: Join buffer: condition is checked in wrong place for range accessbb-10.3-mdev21243Sergei Petrunia2020-01-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In this scenario: - There is a possible range access for table T - And there is a ref access on the same index which uses fewer key parts - The join optimizer picks the ref access (because it is cheaper) - make_join_select applies this heuristic to switch to range: /* Range uses longer key; Use this instead of ref on key */ Join buffer will be used without having called JOIN_TAB::make_scan_filter(). This means, conditions that should be checked when reading table T will be checked after T is joined with the contents of the join buffer, instead. Fixed this by adding a make_scan_filter() check. (updated patch after backport to 10.3) (Fix testcase on Windows)
* | | Merge 10.2 into 10.3Marko Mäkelä2019-12-271-3/+33
|\ \ \ | |/ /
| * | MDEV-21318: Wrong results with window functions and implicit groupingVarun Gupta2019-12-261-1/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue here is for degenerate joins we should execute the window function but it is not getting executed in all the cases. To get the window function values window function needs to be executed always. This currently does not happen in few cases where the join would return 0 or 1 row like 1) IMPOSSIBLE WHERE 2) MIN/MAX optimization 3) EMPTY CONST TABLE The fix is to make sure that window functions get executed and the temporary table is setup for the execution of window functions
| * | Merge 10.1 into 10.2Marko Mäkelä2019-12-231-1/+1
| |\ \ | | |/
| | * MDEV-21341: Fix optimizer-related UBSAN failures, part #1:Sergei Petrunia2019-12-181-1/+1
| | | | | | | | | | | | Fix wrong typecast
View Lorry Controller Status