summaryrefslogtreecommitdiff
path: root/mysql-test/main
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-22761: innodb row_search_idx_cond_check handle CHECK_ABORTED_BY_USERSergei Petrunia2020-10-1410-5/+236
| | | | | | | | | | | Part #2: - row_search_mvcc() should return DB_INTERRUPTED when it got - Move the sync point from innodb internals to handler_rowid_filter_check() where other storage engines can use it too - Add a similar syncpoint for the ICP check. - Add a bigger test and test coverage for Rowid Filter with MyISAM - Add test coverage for killed-during-ICP-check scenario
* MDEV-22761: innodb row_search_idx_cond_check handle CHECK_ABORTED_BY_USERDaniel Black2020-10-142-0/+72
| | | | | | | | | | | | handler_rowid_filter_check can return CHECK_ABORTED_BY_USER. All the functions that call row_search_idx_cond_check handle the CHECK_ABORTED_BY_USER return value. So return it rather than generating an error. This incorrect handling was introduced in MDEV-21794 (8d85715d507d). Reviewer: Marko Mäkelä
* MDEV-23518 Syntax error in ond SP results in misleading message on SHOW ↵Oleksandr Byelkin2020-10-036-8/+119
| | | | | | CREATE PROCEDURE Add info to the error message how to get details about error which happened.
* Reverted wrong patch for mysql_upgradeMonty2020-09-251-2/+2
| | | | | The original code was correct. mysql_upgrade calls the mysql client to talk with MariaDB. It doesn't call itself!
* MDEV-23318 Assertion `cache_empty(keycache)' failed in ↵Monty2020-09-252-0/+108
| | | | | | | | | prepare_resize_simple_key_cache The reason was that during MyISAM parallel repair two threads used the same changed TABLE object to compute virtual columns Fixed by adding a mutex in compute_vcols()
* MDEV-21470 ASAN heap-use-after-free in my_hash_sort_binMonty2020-09-252-0/+35
| | | | | | | The problem was that the server was calling virtual functions on a record that was not initialized with new data. This happened when fill_record() was aborted in the middle because an error in save_val() or save_in_field()
* Merge 10.3 into 10.4Marko Mäkelä2020-09-225-2/+60
|\
| * Merge 10.2 into 10.3Marko Mäkelä2020-09-225-2/+56
| |
* | Merge 10.3 into 10.4Marko Mäkelä2020-09-212-0/+15
|\ \ | |/
| * MDEV-23741: Fix the resultMarko Mäkelä2020-09-211-1/+1
| |
| * MDEV-23741 Windows : error when renaming file in ALTER TABLEVladislav Vaintroub2020-09-172-0/+15
| | | | | | | | | | | | | | | | | | | | The presumed reason for the error is that the file was opened by 3rd party antivirus or backup program, causing ERROR_SHARING_VIOLATION on rename. The fix, actually a workaround, is to retry MoveFileEx couple of times before finally giving up. We expect 3rd party programs not to hold file for extended time.
* | Merge 10.3 into 10.4Marko Mäkelä2020-09-0312-669/+558
|\ \ | |/
| * Merge 10.2 into 10.3Marko Mäkelä2020-09-0310-652/+495
| |
| * MDEV-16372 ER_BASE64_DECODE_ERROR upon replaying binary log via mysqlbinlog ↵Andrei Elkin2020-08-312-16/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | --verbose (This commit is for 10.3 and upper branches) In case of a pattern of non-STMT_END-marked Rows-log-event (A) followed by a STMT_END marked one (B) mysqlbinlog mixes up the base64 encoded rows events with their pseudo sql representation produced by the verbose option: BINLOG ' base64 encoded data for A ### verbose section for A base64 encoded data for B ### verbose section for B '/*!*/; In effect the produced BINLOG '...' query is not valid and is rejected with the error. Examples of this way malformed BINLOG could have been found in binlog_row_annotate.result that gets corrected with the patch. The issue is fixed with introduction an auxiliary IO_CACHE to hold on the verbose comments until the terminal STMT_END event is found. The new cache is emptied out after two pre-existing ones are done at that time. The correctly produced output now for the above case is as the following: BINLOG ' base64 encoded data for A base64 encoded data for B '/*!*/; ### verbose section for A ### verbose section for B Thanks to Alexey Midenkov for the problem recognition and attempt to tackle, and to Venkatesh Duggirala who produced a patch for the upstream whose idea is exploited here, as well as to MDEV-23077 reporter LukeXwang who also contributed a piece of a patch aiming at this issue.
* | Make rowid_filter_innodb test stableSergei Petrunia2020-09-033-0/+13
| | | | | | | | It was failing on mac-1012-bintar.
* | MDEV-23094: Multiple calls to a Stored Procedure from another Stored ↵bb-10.4-MDEV-23094Oleksandr Byelkin2020-08-312-0/+186
| | | | | | | | | | | | | | | | Procedure crashes server Added system-SELECT to IF/WHILE/REPET/FOR for correct subqueries connecting. Added control of system/usual selects for correct error detection.
* | Merge 10.3 into 10.4Marko Mäkelä2020-08-264-0/+81
|\ \ | |/
| * MDEV-18335: Assertion `!error || error == 137' failed in ↵Varun Gupta2020-08-262-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | subselect_rowid_merge_engine::init When duplicates are removed from a table using a hash, if the record is a duplicate it is marked as deleted. The handler API check if the record is deleted and send an error flag HA_ERR_RECORD_DELETED. When we scan over the table if the thread is not killed then we skip the records marked as HA_ERR_RECORD_DELETED. The issue here is when a query is aborted by a user (this is happening when the LIMIT for ROWS EXAMINED is exceeded), the scan over the table does not skip the records for which HA_ERR_RECORD_DELETED is sent. It just returns an error flag HA_ERR_ABORTED_BY_USER. This error flag is not checked at the upper level and hence we hit the assert. If the query is aborted by the user we should just skip reading rows and return control to the upper levels of execution.
| * MDEV-23467 SIGSEGV in fill_record/fill_record_n_invoke_before_triggers on ↵Aleksey Midenkov2020-08-252-0/+14
| | | | | | | | | | | | | | | | | | INSERT DELAYED Field::make_new_field() resets invisible property (needed for "CREATE .. SELECT" f.ex.). Recover invisible property in Delayed_insert::get_local_table() (unireg_check works by the same principle).
* | MDEV-23525 Wrong result of MIN(time_expr) and MAX(time_expr) with GROUP BYAlexander Barkov2020-08-222-0/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: When calculatung MIN() and MAX() in a query with GROUP BY, like this: SELECT MIN(time_expr), MAX(time_expr) FROM t1 GROUP BY i; the code in Item_sum_min_max::update_field() erroneosly used string format comparison, therefore '100:20:30' was considered as smaller than '10:20:30'. Fix: 1. Implementing low level "native" related methods in class Time: Time::Time(const Native &native) - convert native to Time Time::to_native(Native *to, uint decimals) - convert Time to native The "native" binary representation for TIME is equal to the binary data format of Field_timef, which is used to store TIME when mysql56_temporal_format is ON (default). 2. Implementing Type_handler_time_common "native" related methods: Type_handler_time_common::cmp_native() Type_handler_time_common::Item_val_native_with_conversion() Type_handler_time_common::Item_val_native_with_conversion_result() Type_handler_time_common::Item_param_val_native() 3. Implementing missing "native representation" related methods in Field_time and Field_timef: Field_time::store_native() Field_time::val_native() Field_timef::store_native() Field_timef::val_native() 4. Implementing missing "native" related methods in all Items that can have the TIME data type: Item_timefunc::val_native() Item_name_const::val_native() Item_time_literal::val_native() Item_cache_time::val_native() Item_handled_func::val_native() 5. Marking Type_handler_time_common as "native ready". So now Item_sum_min_max::update_field() calculates values using min_max_update_native_field(), which uses native binary representation rather than string representation. Before this change, only the TIMESTAMP data type used native representation to calculate MIN() and MAX(). Benchmarks (see more details in MDEV): This change not only fixes the wrong result, but also makes a "SELECT .. MAX.. GROUP BY .." query faster: # TIME(0) CREATE TABLE t1 (id INT, time_col TIME) ENGINE=HEAP; INSERT INTO t1 VALUES (1,'10:10:10'); -- repeat this 1m times SELECT id, MAX(time_col) FROM t1 GROUP BY id; MySQL80: 0.159 sec 10.3: 0.108 sec 10.4: 0.094 sec (fixed) # TIME(6): CREATE TABLE t1 (id INT, time_col TIME(6)) ENGINE=HEAP; INSERT INTO t1 VALUES (1,'10:10:10.999999'); -- repeat this 1m times SELECT id, MAX(time_col) FROM t1 GROUP BY id; My80: 0.154 10.3: 0.135 10.4: 0.093 (fixed)
* | Merge 10.3 into 10.4Marko Mäkelä2020-08-214-5/+5
|\ \ | |/
| * Merge 10.2 into 10.3Marko Mäkelä2020-08-214-5/+5
| |
* | Merge 10.3 into 10.4Marko Mäkelä2020-08-201-0/+6
|\ \ | |/
| * Merge 10.2 into 10.3Marko Mäkelä2020-08-201-0/+6
| |
* | Merge 10.3 into 10.4, except MDEV-22543Marko Mäkelä2020-08-132-0/+9
|\ \ | |/ | | | | Also, fix GCC -Og -Wmaybe-uninitialized in run_backup_stage()
| * Merge 10.2 into 10.3Marko Mäkelä2020-08-132-0/+9
| |
* | Merge 10.3 into 10.4Marko Mäkelä2020-08-112-8/+13
|\ \ | |/
| * Work around MDEV-23445 in the MDEV-14836 test caseMarko Mäkelä2020-08-113-5/+27
| |
* | After-merge fix of a resultMarko Mäkelä2020-08-111-0/+18
| | | | | | | | | | | | | | In the merge eae968f62d285de97ed607c87bc131cd863d5d03, it turns out that I had accidentally initiated an in-source build in the past, and $MYSQL_TZINFO_TO_SQL was pointing to a stale copy of the executable in the source directory, instead of the correct one in the build directory.
* | Merge 10.3 into 10.4Marko Mäkelä2020-08-1018-19/+328
|\ \ | |/
| * Merge 10.2 into 10.3Marko Mäkelä2020-08-1014-19/+312
| |
| * Merge mariadb-10.3.24Marko Mäkelä2020-08-1016-15/+493
| |\
| * | MDEV-22022 Various mangled SQL statements will crash 10.3 to 10.5 debug buildsAlexander Barkov2020-08-044-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lex_input_stream::scan_ident_delimited() could go beyond the end of the input when a starting backtick (`) delimiter did not have a corresponding ending backtick. Fix: catch the case when yyGet() returns 0, which means either eof-of-query or straight 0x00 byte inside backticks, and make the parser fail on syntax error, displaying the left backtick as the syntax error place. In case of filename in a script like this: SET CHARACTER_SET_CLIENT=17; -- 17 is 'filename' SELECT doc.`Children`.0 FROM t1; the ending backtick was not recognized as such because my_charlen() returns 0 for a straight backtick (backticks must normally be encoded as @0060 in filename). The same fix works for 'filename': the execution skips the backtick and reaches the end of the query, then yyGet() returns 0. This fix is OK for now. But eventually 'filename' should either be disallowed as a parser character set, or fixed to handle encoded punctuation properly.
| * | Fix named_pipe test so it can be used with --repeatVladislav Vaintroub2020-08-031-0/+1
| | | | | | | | | | | | | | | Remove the error log of the mysqld instance that was attempted to start in the test.
* | | Merge mariadb-10.4.14Marko Mäkelä2020-08-1019-16/+518
|\ \ \
| * | | MDEV-23358 main.upgrade_MDEV-19650 fails with result differenceSergei Golubchik2020-08-051-1/+0
| | | | | | | | | | | | | | | | no it doesn't
| * | | Merge branch '10.3' into 10.4Oleksandr Byelkin2020-08-0318-15/+518
| |\ \ \ | | | |/ | | |/|
| | * | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-08-0316-15/+493
| | |/
| | * MDEV-21201: Add --sorted_result to the test, for 10.4Marko Mäkelä2020-08-011-0/+5
| | | | | | | | | | | | | | | | | | | | | On MariaDB 10.4 (commit 4db4b773653eacba029631363ef1abdd5242b71a), the query results would not be sorted, which creates random result differences. Let us explicitly sort the results already in 10.3 in order to avoid future merge trouble.
| | * MDEV-19632 Replication aborts with ER_SLAVE_CONVERSION_FAILED upon CREATE ↵Alexander Barkov2020-08-012-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... SELECT in ORACLE mode - Adding optional qualifiers to data types: CREATE TABLE t1 (a schema.DATE); Qualifiers now work only for three pre-defined schemas: mariadb_schema oracle_schema maxdb_schema These schemas are virtual (hard-coded) for now, but may turn into real databases on disk in the future. - mariadb_schema.TYPE now always resolves to a true MariaDB data type TYPE without sql_mode specific translations. - oracle_schema.DATE translates to MariaDB DATETIME. - maxdb_schema.TIMESTAMP translates to MariaDB DATETIME. - Fixing SHOW CREATE TABLE to use a qualifier for a data type TYPE if the current sql_mode translates TYPE to something else. The above changes fix the reported problem, so this script: SET sql_mode=ORACLE; CREATE TABLE t2 AS SELECT mariadb_date_column FROM t1; is now replicated as: SET sql_mode=ORACLE; CREATE TABLE t2 (mariadb_date_column mariadb_schema.DATE); and the slave can unambiguously treat DATE as the true MariaDB DATE without ORACLE specific translation to DATETIME. Similar, SET sql_mode=MAXDB; CREATE TABLE t2 AS SELECT mariadb_timestamp_column FROM t1; is now replicated as: SET sql_mode=MAXDB; CREATE TABLE t2 (mariadb_timestamp_column mariadb_schema.TIMESTAMP); so the slave treats TIMESTAMP as the true MariaDB TIMESTAMP without MAXDB specific translation to DATETIME.
* | | MDEV-23415 Server crash or Assertion `dec_length <= str_length' failed in ↵Alexander Barkov2020-08-082-0/+190
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Item_func_format::val_str_ascii Problem: The crash happened in FORMAT(double, dec>=31, 'de_DE'). The patch for MDEV-23118 (commit 0041dacc1b8e85e1958355d1cfdc36055b05a884) did not take into account that String::set_real() has a limit of 31 (FLOATING_POINT_DECIMALS) fractional digits. So for the range of 31..38 digits, set_real() switches to use: - my_fcvt() - decimal point notation, e.g. 1.9999999999 - my_gcvt() - scientific notation, e.g. 1e22 my_gcvt() returned a shorter string than Item_func_format::val_str_ascii() expected to get after the my_fcvt() call, so it crashed on assert. Solution: We cannot extend set_real() to use the my_fcvt() mode for the range of 31..38 fractional digits, because set_real() is used in a lot of places and such a change will break everything. Introducing String::set_fcvt() which always prints using my_fcvt() for the whole range of decimals 0..38, supported by the FORMAT() function.
* | | MDEV-23118 FORMAT(d1,dec) where dec=0/38 and d1 is DECIMAL(38,38) gives ↵Alexander Barkov2020-08-054-5/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | incorrect results FORMAT() can print more integer digits (than the argument has) if rounding happens: FORMAT(9.9,0) -> '10' The old code did not take this into account. Fix: 1. One extra digit is needed in case of rounding - If args[1] is a not-NULL constant, then reserve space for one extra integer digit if the requested number of decimals is less than args[0]->decimals. - Otherwise, reserve space for one extra integer digit if args[0]->decimals is not 0, because rounding can potentially happen (depending on the exact data in arguments). 2. One extra digit is also needed if the argument has no integer digits, e.g. in a data type like DECIMAL(38,38). The conditions 1 and 2 are ORed. 3. Fixing FORMAT_MAX_DECIMALS from 30 to 38. This was forgotten in 10.2.1 (when the limit for the number of fractional digits in DECIMAL was extended).
* | | MDEV-23388 Assertion `args[0]->decimals == 0' failed in ↵Alexander Barkov2020-08-042-0/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Item_func_round::fix_arg_int Type_handler_temporal_result::Item_func_min_max_fix_attributes() in an expression GREATEST(string,date), e.g: SELECT GREATEST('1', CAST('2020-12-12' AS DATE)); incorrectly evaluated decimals as 6 (like for DATETIME). Adding a separate virtual implementation: Type_handler_date_common::Item_func_min_max_fix_attributes() This makes the code simpler.
* | | MDEV-23032 FLOOR()/CEIL() incorrectly calculate the precision of a ↵Alexander Barkov2020-08-048-136/+483
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DECIMAL(M,D) column The code in Item_func_int_val::fix_length_and_dec_int_or_decimal() calculated badly the result data type for FLOOR()/CEIL(), so for example the decimal(38,10) input created a decimal(28,0) result. That was not correct, because one extra integer digit is needed. floor(-9.9) -> -10 ceil(9.9) -> 10 Rewritting the code in a more straightforward way. Additional changes: - FLOOR() now takes into account the presence of the UNSIGNED flag of the argument: FLOOR(unsigned decimal) does not need an extra digits. - FLOOR()/CEILING() now preserve the unsigned flag in the result data type is decimal. These changes give nicer data types.
* | MDEV-23366 ROUND(18446744073709551615,rand()*0) returns a wrong resultAlexander Barkov2020-08-035-8/+256
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Changing that in case of *INT and hex hybrid input: - ROUND(x,NULL) creates a column with the same type as x. The old code created a DOUBLE column, which was not relevant at all. This change simplifies the code a lot. - ROUND(x,non_constant) creates a column of the INT, BIGINT or DECIMAL data type (depending on the exact type of x). The old code created a column of the DOUBLE data type, which lead to precision loss. Hence MDEV-23366. - ROUND(bigint_30,negative_constant) creates a column of the DECIMAL(30,0) data type. The old code created DECIMAL(29,0), which looked strange: the data type promoted to a higher one, but max length reduced. Now the length attribute is preserved.
* | MDEV-21017: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())'Rucha Deodhar2020-08-032-0/+33
| | | | | | | | | | | | | | | | | | failed or late ER_PERIOD_FIELD_WRONG_ATTRIBUTES upon attempt to create existing table Analysis: Error state is not stored when field is checked in Table_period_info::check_field() Fix: Store error state by setting res to true.
* | MDEV-23367 ROUND(18446744073709551615,-1) returns a wrong resultAlexander Barkov2020-08-032-0/+423
| | | | | | | | This problem was fixed by MDEV-23368. Adding tests only.
* | MDEV-23368 ROUND(18446744073709551615,-11) returns a wrong resultAlexander Barkov2020-08-024-0/+56
| | | | | | | | | | | | | | | | Item_func_round::fix_arg_int() did not take into account cases when the result of ROUND(bigint_subject,negative_precision) could go outside of the BIGINT range. The old code only incremented max_length, but did not extend change the data type. Fixing to extend the data type (together with max_length increment).
* | MDEV-23350 ROUND(bigint_22_or_longer) returns a wrong data typeAlexander Barkov2020-08-022-2/+334
| | | | | | | | | | | | | | | | | | | | | | | | | | The condition in Item_func_round::fix_arg_int() to decide whether: - we can preserve the data type of args[0] versus - the result can go outside of the args[0] data type was wrong. The data type of the first argument can be preserved in these cases: - TRUNCATE(x, n) - ROUND(x, n>=0) Fixing the condition accordingly.
* | Merge 10.3 into 10.4Marko Mäkelä2020-08-012-5/+10
|\ \
View Lorry Controller Status