summaryrefslogtreecommitdiff
path: root/mysql-test/main
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch '10.3' into 10.4Oleksandr Byelkin2019-05-19102-136/+2549
|\
| * Merge branch '10.2' into 10.3Sergei Golubchik2019-05-172-2/+116
| |
| * Merge 10.2 into 10.3Marko Mäkelä2019-05-165-0/+133
| |
| * MDEV-16872 Add CAST(expr AS FLOAT)Alexander Barkov2019-05-166-4/+123
| |
| * MDEV-19468 Hybrid type expressions return wrong format for FLOATAlexander Barkov2019-05-156-22/+96
| |
| * Merge 10.2 into 10.3Marko Mäkelä2019-05-142-0/+28
| |
| * Merge branch '10.2' into 10.3Oleksandr Byelkin2019-05-1286-104/+1454
| |
| * MDEV-17894 Assertion `(thd->lex)->current_select' failed in MYSQLparse(),Igor Babaev2019-05-082-0/+590
| | | | | | | | | | | | | | | | | | | | query with VALUES() A table value constructor can be used in all contexts where a select can be used. In particular an ORDER BY clause or a LIMIT clause or both of them can be attached to a table value constructor to produce a new query. Unfortunately execution of such queries was not supported. This patch fixes the problem.
| * MDEV-17710 "unknown error" with FLUSH LOGS if log directory is not writeableSergei Golubchik2019-05-072-0/+16
| |
* | fix tcp disconnect and perlOleksandr Byelkin2019-05-192-4/+11
| |
* | More fixed for perl testOleksandr Byelkin2019-05-191-3/+4
| |
* | Fix default_password_lifetime message typoRobert Bindar2019-05-181-1/+1
| | | | | | | | Closes #1212
* | MDEV-8919 Wrong result for CAST(9999999999999999999.0)Alexander Barkov2019-05-172-2/+150
| |
* | MDEV-19134: EXISTS() slower if ORDER BY is definedSergei Petrunia2019-05-163-14/+57
| | | | | | | | | | | | | | Step #2: "[ORDER BY ...] LIMIT n" should not prevent EXISTS-to-IN conversion, as long as - the LIMIT clause doesn't have OFFSET - the LIMIT is not "LIMIT 0".
* | MDEV-19134: EXISTS() slower if ORDER BY is definedSergei Petrunia2019-05-167-16/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Step 1: Removal of ORDER BY [LIMIT] from the subquery should be done earlier and for broader class of subqueries. The rewrite was done in Item_in_subselect::select_in_like_transformer(), but this had problems: - It didn't cover EXISTS subqueries - It covered IN-subqueries, but was done after the semi-join transformation was considered inapplicable, because ORDER BY was present. Remaining issue: - EXISTS->IN transformation happens before check_and_do_in_subquery_rewrites() is called, so it is still prevented by the present ORDER BY.
* | fix the test for windowsbb-10.4-sanjaOleksandr Byelkin2019-05-152-16/+6
| |
* | Added a 32 bit rdiff for myisam_mrr instead of a 64 bit rdiffVarun Gupta2019-05-153-33/+15
| |
* | Fixed ya main.flush_read_lock sporadic failureSergey Vojtovich2019-05-142-8/+9
| | | | | | | | | | Use different signal names, so that subsequent WAIT_FOR is not awaken by previous signal.
* | MDEV-19277: Add status variable that gets incremented if connection is ↵Oleksandr Byelkin2019-05-142-0/+88
| | | | | | | | | | | | aborted prior to authentication MDEV-19282: Log more specific warning with log_warnings=2 if connection is aborted prior to authentication
* | Fixed myisam_mrr for 32 bit systemsVarun Gupta2019-05-131-2/+2
| |
* | Fixed main.flush_read_lock sporadic failureSergey Vojtovich2019-05-132-10/+21
| | | | | | | | | | | | With MDEV-19384 fixed FTWRL releases HANDLER locks early, which allows concurrent threads to go. Test case may get stuck on FTWRL waiting for LOCK TABLES.
* | MDEV-13628: ORed condition in pushed index condition is not removed from the ↵Varun Gupta2019-05-1117-37/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WHERE So to push index condition for each join tab we have calculate the index condition that can be pushed and then remove this index condition from the original condition. This is done through the function make_cond_remainder. The problem is the function make_cond_remainder does not remove index condition when there is an OR operator. Fixed this by making the function make_cond_remainder to keep in mind of the OR operator. Also updated results for multiple test files which were incorrectly updated by the commit e0c1b3f24246d22e6785315f9a8448bd9a590422 code which was supposed to remove the condition present in the index condition was not getting executed when the condition had OR operator, with AND the pushed index condition was getting removed from where. This problem affects all versions starting from 5.5 but this is a performance improvement, so fixing it in 10.4
* | MDEV-8553: Impossible where for a!=a, a<a, a>aDaniel Black2019-05-102-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For a table column `a`, the above expressions logically equate to false in all cases. With this patch the optimizer knows about this and queries like: SELECT * FROM t1 WHERE a!=a no longer need to evaluate a!=a for every row. The same applies if the expression was `a<a`, or `a>a` An `EXPLAIN SELECT COOUNT(*) FROM t1 WHERE a<a` will show: id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Impossible WHERE Similarly `NOT (a!=a)` is always true. EXPLAIN SELECT COUNT(*) FROM t1 WHERE not (a!=a); id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE NULL NULL NULL NULL NULL NULL NULL Select tables optimized away
* | MDEV-19235 MariaDB Server compiled for 128 Indexes crashes at startupbb-10.4-wlad-MDEV-19235Vladislav Vaintroub2019-05-092-128/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With MAX_INDEXIES=64(default), key_map=Bitmap<64> is just a wrapper around ulonglong and thus "trivial" (can be bzero-ed, or memcpy-ed, and stays valid still) With MAX_INDEXES=128, key_map = Bitmap<128> is not a "trivial" type anymore. The implementation uses MY_BITMAP, and MY_BITMAP contains pointers which make Bitmap invalid, when it is memcpy-ed/bzero-ed. The problem in 10.4 is that there are many new key_map members, inside TABLE or KEY, and those are often memcopied and bzeroed The fix makes Bitmap "trivial", by inlining most of MY_BITMAP functionality. pointers/heap allocations are not used anymore.
* | MDEV-18689 Simple query with extra brackets stopped workingIgor Babaev2019-05-0619-103/+235
| | | | | | | | | | | | | | | | Parenthesis around table names and derived tables should be allowed in FROM clauses and some other context as it was in earlier versions. Returned test queries that used such parenthesis in 10.3 to their original form. Adjusted test results accordingly.
* | MDEV-19384 Deadlock in FTWRLMonty2019-05-062-0/+77
| | | | | | | | | | | | | | | | | | | | | | The deadlock happened between FTWRL under open HANDLER, LOCK TABLE and DROP DATABASE Fixed by reverting the previous fix for handler open in lock_global_read_lock() Fixed the original (wrong) test case in flush_read_lock.test to be repeatable.
* | Merge 10.3 into 10.4Marko Mäkelä2019-05-0518-35/+230
|\ \ | |/
| * MDEV-18943: Group Concat with limit not working with viewsVarun Gupta2019-05-032-0/+26
| | | | | | | | | | Adjusted the Item_func_group_concat::print function to take into account limit if present with GROUP_CONCAT
| * Merge 10.2 into 10.3Marko Mäkelä2019-05-024-18/+91
| |
| * MDEV-17655 Inconsistent grant-name usage between grant-statement and ↵Aleksey Midenkov2019-05-023-7/+7
| | | | | | | | | | | | privilege tables Closes #1044
| * Adjust the result for join_cache.testVarun Gupta2019-05-021-3/+3
| |
| * MDEV-9959: A serious MariaDB server performance bugVarun Gupta2019-04-306-7/+91
| | | | | | | | | | If a derived table has SELECT DISTINCT, provide index statistics for it so that the join optimizer in the upper select knows that ref access to the table will produce one row.
| * MDEV-10307 CAST(11068046444225730969 AS SIGNED) does not return a warningAlexander Barkov2019-04-303-0/+27
| |
* | Merge 10.3 into 10.4Marko Mäkelä2019-05-052-0/+89
|\ \ | |/
| * Merge 10.2 into 10.3Marko Mäkelä2019-04-272-0/+89
| |
* | MDEV-18117: Crash with Explain extended when using limit rows examinedVarun Gupta2019-05-032-0/+27
| | | | | | | | | | No need to set SELECT_LEX:explicit_limit when we have a limit clause that sets only the EXAMINED ROWS
* | Enable mysqlcheck and flush_read_lock testsMonty2019-05-026-20/+19
| | | | | | | | | | | | | | | | - Updated results - Run mysqlcheck without --user-stat-tables=PREFERABLY to keep results consistent - Don't allow one to run analyze table under FTWRL as analyze table nowadays has to update status tables.
* | MDEV-19363 Assertion `select_lex' failed in LEX::pop_selectIgor Babaev2019-05-012-0/+74
| | | | | | | | | | | | | | | | This patch corrects the patch for MDEV-19324. The latter did not work properly in the cases when the transformation (SELECT ... ORDER BY ...) LIMIT ... => SELECT ... ORDER BY ... LIMIT ... was applied to the operands of a set operation.
* | Test for MDEV-11874 "Data too long for column" instead of "Invalid default ↵Alexander Barkov2019-04-292-0/+68
| | | | | | | | | | | | | | | | | | value for" upon ALTER in strict mode This problem was earlier fixed by the patch for: MDEV-16421 Make system tables crash safe Adding tests only.
* | MDEV-19324 Wrong results from query, using brackets with ORDER BY ..LIMITIgor Babaev2019-04-262-0/+183
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a select query was of the form (SELECT ... ORDER BY ...) LIMIT ... then in most cases it returned incorrect result. It happened because SELECT ... ORDER BY ... was wrapped into a select with materialized derived table: SELECT ... ORDER BY ... => SELECT * FROM (SELECT ... ORDER BY ...) dt. Yet for any materialized derived table ORDER BY without LIMIT is ignored. This patch resolves the problem by the conversion (SELECT ... ORDER BY ...) LIMIT ... => SELECT ... ORDER BY ... LIMIT ... at the parser stage. Similarly ((SELECT ... UNION ...) ORDER BY ...) LIMIT ... is converted to (SELECT ... UNION ...) ORDER BY ... LIMIT ... This conversion optimizes execution of the query because the result of (SELECT ... UNION ...) ORDER BY ... is not materialized into a temporary table anymore.
* | Merge 10.3 into 10.4Marko Mäkelä2019-04-2526-28/+881
|\ \ | |/ | | | | | | In is_eits_usable(), we disable an assertion that fails due to MDEV-19334.
| * Merge 10.2 into 10.3Marko Mäkelä2019-04-2515-0/+431
| |
| * MDEV-19239 ERROR 1300 (HY000): Invalid utf8 character string in 10.3.13-MariaDBAlexander Barkov2019-04-212-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A sequence of <digits>e<mbhead><mbtail>, e.g.: SELECT 123eXYzzz FROM t1; was not scanned correctly (where XY is a multi-byte character). The multi-byte head byte X was appended to 123e separately from the multi-byte tail byte Y, so a pointer to "Yzzz" was passed into scan_ident_start(), which failed on a bad multi-byte sequence. After this change, scan_ident_start() gets a pointer to "XYzzz", so it correctly sees the whole multi-byte character.
| * Backporting from 10.4 to 10.3: MDEV-17325 NULL-ability problems with LEAST() ↵Alexander Barkov2019-04-204-1/+216
| | | | | | | | | | | | | | | | | | | | in combination with NO_ZERO_DATE and NO_ZERO_IN_DATE This also fixes: MDEV-17299 Assertion `maybe_null' failed in make_sortkey Note, during merge of the 10.1 version of MDEV-17299, please use the 10.3 version of the code (i.e. null merge the 10.1 version).
* | MDEV-19317 TEXT column accepts too long literals as a default valueAlexander Barkov2019-04-252-0/+67
| | | | | | | | | | | | | | | | | | Adding new virtual methods in Field: - make_empty_rec_store_default_value() - make_empty_rec_reset() This simplifies the logic for every Field type, and makes the code more friendly to pluggable data types.
* | MDEV-19245: Impossible WHERE should be noticed earlier after HAVING pushdownbb-10.4-galinaGalina Shalygina2019-04-222-0/+74
| | | | | | | | | | | | | | | | The bug appears because not all conditions are found to be knowingly true or false in WHERE after HAVING pushdown optimization. Impossible WHERE can be found much earlier compared with how it is done now. To fix it and_new_conditions_to_optimized_cond() is changed.
* | MDEV-19255 Server crash in st_join_table::save_explain_data or assertionIgor Babaev2019-04-193-0/+223
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `sel->quick' failure in JOIN::make_range_rowid_filters upon query with rowid_filter=ON Index ranges can be defined using conditions with inexpensive subqueries. Such a subquery is evaluated when some representation of a possible range sequence is built. After the evaluation the JOIN structure of the subsquery is distroyed. Any attempt to build the above representation may fail because the function that checks whether a subquery is inexpensive in some cases uses the join structure of the subquery. When a range rowid filter is built by a range sequence constructed out of a range condition that uses an inexpensive subquery the representation of the the sequence is built twice. Building the second representation fails due to the described problem with the execution of Item_subselect::is_expensive(). The function was corrected to return the result of the last its invocation if the Item_subselect object has been already evaluated.
* | MDEV-19224 Assertion `marked_for_read()' failedMonty2019-04-192-0/+15
| | | | | | | | | | Problem was that wrong key_info variable was used, which caused UNIQUE key to be used as a covering key
* | MDEV-19252 Problem with DBUG_ASSERT_AS_PRINTF and marked_for_write()Monty2019-04-192-0/+16
| | | | | | | | | | Problem was that DBUG_FIX_WRITE_SET was not enabled when using DBUG_ASSERT_AS_PRINTF
* | MDEV-19164 Assertion `fixed' failed in Item_func_inet_aton::val_intIgor Babaev2019-04-172-0/+106
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When pushing a condition from HAVING into WHERE the function st_select_lex::pushdown_from_having_into_where() transforms column references in the pushed condition then performs cleanup of items of the condition and finally calls fix_fields() for the condition items. The cleanup is performed by a call of the method walk() with cleanup_processor as the first parameter. Unfortunately this sequence of calls does not work if the condition contains cached items, because fix_fields() cannot go through Item_cache items and this leaves underlying items unfixed. The solution of this problem used in this patch is just does not allow to process Item_cache objects when performing cleanup of the pushed condition. In order to let the traversal procedure walk() not to process Item_cache objects the third parameter of the used call of walk() is set to a fictitious pointer (void *) 1. And Item_cache::walk() is changed to prevent any action when it gets such value as the third parameter.
View Lorry Controller Status