summaryrefslogtreecommitdiff
path: root/sql
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-17351 Wrong results for GREATEST,TIMESTAMP,ADDTIME with an out-of-range ↵Alexander Barkov2018-10-085-39/+257
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TIME-alike argument Problems: Functions LEAST() and GREATEST() in TIME context, as well as functions TIMESTAMP(a,b) and ADDTIME(a,b), returned confusing results when the input TIME-alike value in a number or in a string was out of the TIME supported range. In case of TIMESTAMP(a,b) and ADDTIME(a,b), the second argument value could get extra unexpected digits. For example, in: ADDTIME('2001-01-01 00:00:00', 10000000) or ADDTIME('2001-01-01 00:00:00', '1000:00:00') the second argument was converted to '838:59:59.999999' with six fractional digits, which contradicted "decimals" previously set to 0 in fix_length_and_dec(). These unexpected fractional digits led to confusing function results. Changes: 1. GREATEST(), LEAST() - fixing Item_func_min_max::get_time_native() to respect "decimals" set by fix_length_and_dec(). If a value of some numeric or string time-alike argument goes outside of the TIME range and gets limited to '838:59:59.999999', it's now right-truncated to the correct fractional precision. - fixing, Type_handler_temporal_result::Item_func_min_max_fix_attributes() to take into account arguments' time_precision() or datetime_precision(), rather than rely on "decimals" calculated by the generic implementation in Type_handler::Item_func_min_max_fix_attributes(). This makes GREATEST() and LEAST() return better data types, with the same fractional precision with what TIMESTAMP(a,b) and ADDTIME(a,b) return for the same arguments, and with DATE(a) and TIMESTAMP(a). 2. Item_func_add_time and Item_func_timestamp It was semantically wrong to apply the limit of the TIME data type to the argument "b", which plays the role of "INTERVAL DAY TO SECOND" here. Changing the code to fetch the argument "b" as INTERVAL rather than as TIME. The low level routine calc_time_diff() now gets the interval value without limiting to '838:59:59.999999', so in these examples: ADDTIME('2001-01-01 00:00:00', 10000000) ADDTIME('2001-01-01 00:00:00', '1000:00:00') calc_time_diff() gets '1000:00:00' as is. The SQL function result now gets limited to the supported result data type range (datetime or time) inside calc_time_diff(), which now calculates the return value using the real fractional digits that came directly from the arguments (without the effect of limiting to the TIME range), so the result does not have any unexpected fractional digits any more. Detailed changes in TIMESTAMP() and ADDTIME(): - Adding a new class Interval_DDhhmmssff. It's similar to Time, but: * does not try to parse datetime format, as it's not needed for functions TIMESTAMP() and ADDTIME(). * does not cut values to '838:59:59.999999' The maximum supported Interval_DDhhmmssff's hard limit is 'UINT_MAX32:59:59.999999'. The maximum used soft limit is: - '87649415:59:59.999999' (in 'hh:mm:ss.ff' format) - '3652058 23:59:59.999999' (in 'DD hh:mm:ss.ff' format) which is a difference between: - TIMESTAMP'0001-01-01 00:00:00' and - TIMESTAMP'9999-12-31 23:59:59.999999' (the minimum datetime that supports arithmetic, and the maximum possible datetime value). - Fixing get_date() methods in the classes related to functions ADDTIME(a,b) and TIMESTAMP(a,b) to use the new class Interval_DDhhmmssff for fetching data from the second argument, instead of get_date(). - Fixing fix_length_and_dec() methods in the classes related to functions ADDTIME(a,b) and TIMESTAMP(a,b) to use Interval_DDhhmmssff::fsp(item) instead of item->time_precision() to get the fractional precision of the second argument correctly. - Splitting the low level function str_to_time() into smaller pieces to reuse the code. Adding a new function str_to_DDhhmmssff(), to parse "INTERVAL DAY TO SECOND" values. After these changes, functions TIMESTAMP() and ADDTIME() return much more predictable results, in terms of fractional digits, and in terms of the overall result. The full ranges of DATETIME and TIME values are now covered by TIMESTAMP() and ADDTIME(), so the following can now be calculated: SELECT ADDTIME(TIMESTAMP'0001-01-01 00:00:00', '87649415:59:59.999999'); -> '9999-12-31 23:59:59.999999' SELECT TIMESTAMP(DATE'0001-01-01', '87649415:59:59.999999') -> '9999-12-31 23:59:59.999999' SELECT ADDTIME(TIME'-838:59:59.999999', '1677:59:59.999998'); -> '838:59:59.999999'
* MDEV-17360 Server crashes in optimize_keyuseIgor Babaev2018-10-071-3/+3
| | | | | | | | | | | | | | This was a bug in the code of MDEV-12387 "Push conditions into materialized subqueries". The bug manifested itself in rather rare situations. An affected query must contain IN subquery predicate whose left operand was an outer field of a mergeable derived table or view and right operand was a materialized subquery. The erroneous code in fact stripped off the Item_direct_ref wrapper from the left operand of the IN subquery predicate when building equalities produced by the conversion of the predicate into a semi-join. As a result the left operand was not considered as an outer reference anymore and used_tables() was calculated incorrectly. This caused a crash in the function optimize_keyuse().
* Merge branch 'bb-10.4-wlad' into 10.4Vladislav Vaintroub2018-10-057-426/+730
|\
| * MDEV-10384 Windows : Refactor threading in mysqld startup.Vladislav Vaintroub2018-10-057-426/+730
| | | | | | | | | | | | | | | | | | | | | | Remove threads that are doing nothing but wait - main thread now handles the connections (if threadpool is used, also threadpool threads would wait for connections) - thread for socket and pipe connections are removed - shutdown thread is now removed, we wait for shutdown notification in main thread as well - kill_server() is also called inside the main thread, after connection loop finished.
* | Merge 10.3 into 10.4Marko Mäkelä2018-10-0567-664/+1121
|\ \
| * \ Merge pull request #847 from tempesta-tech/tt-10.3-MDEV-16211Jan Lindström2018-10-022-0/+2
| |\ \ | | | | | | | | MDEV-16211 Contents of transaction_registry should not be replicated by Galera
| | * | MDEV-16211 Contents of transaction_registry not replicated by GaleraEugene Kosov2018-10-012-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Patch fixes two bugs: 1) BEGIN_TIMESTAMP of MYSQL.TRANSACTION_REGISTY is '0-0-0' on replication record insertion 2) BEGIN_TIMESTAMP equals COMMMIT_TIMESTAMP in MYSQL.TRANSACTION_REGISTRY Fixed by calling THD::set_time() at appropriate places
| * | | MDEV-17167 - InnoDB: Failing assertion: table->get_ref_count() == 0 uponmariadb-10.3.10Sergey Vojtovich2018-10-024-1/+39
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | truncating a temporary table TRUNCATE expects only one TABLE instance (which is used by TRUNCATE itself) to be open. However this requirement wasn't enforced after "MDEV-5535: Cannot reopen temporary table". Fixed by closing unused table instances before performing TRUNCATE.
| * | ASAN error when strlen(db) < 6Sergei Golubchik2018-09-281-1/+2
| | |
| * | Merge branch '10.2' into 10.3Sergei Golubchik2018-09-2861-629/+992
| |\ \
| | * \ Merge branch '10.1' into 10.2Sergei Golubchik2018-09-2415-310/+101
| | |\ \
| | | * \ Merge branch '10.0' into 10.1Sergei Golubchik2018-09-2314-302/+88
| | | |\ \
| | | | * \ Merge remote-tracking branch 'origin/5.5' into bb-10.0-barbb-10.0-barAlexander Barkov2018-09-212-2/+6
| | | | |\ \
| | | | | * | Fixing the comment not to mention the removed class Item_copy_int.Alexander Barkov2018-09-211-1/+1
| | | | | | |
| | | | | * | A cleanup for MDEV-17249 MAKETIME(-1e50,0,0) returns a wrong resultAlexander Barkov2018-09-211-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Unary minus operation for the smallest possible signed long long value (LONLONG_MIN) is undefined in C++. Because of this, func_time.test failed on ppc64 buildbot machines. Fixing the code to avod using undefined operations. This is fix is similar to "MDEV-7973 bigint fail with gcc 5.0"
| | | | * | | Merge remote-tracking branch 'origin/5.5' into 10.0Alexander Barkov2018-09-2113-304/+96
| | | | |\ \ \ | | | | | |/ /
| | | | | * | MDEV-17250 Remove unused Item_copy_xxxAlexander Barkov2018-09-202-265/+0
| | | | | | |
| | | | | * | MDEV-17244 MAKETIME(900,0,0.111) returns a wrong resultAlexander Barkov2018-09-201-3/+4
| | | | | | |
| | | | | * | MDEV-17249 MAKETIME(-1e50,0,0) returns a wrong resultAlexander Barkov2018-09-209-32/+88
| | | | | | |
| | | | | * | MDEV-16741 Assertion `m_extra_cache' failed in ha_partition::late_extra_cacheEugene Kosov2018-09-102-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | multi_delete sets TABLE::no_cache=1 and should set it to 0 when DELETE is done.
| | | | | * | Bug#27407480: AUTOMATIC_SP_PRIVILEGES REQUIRES NEED THE INSERT PRIVILEGES ↵Sergei Golubchik2018-09-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FOR MYSQL.USER TABLE A test case and a followup fix
| | | | * | | MDEV-14410 - Assertion `table->pos_in_locked_tables == __null ||Sergey Vojtovich2018-09-182-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | table->pos_in_locked_tables->table == table' failed in mark_used_tables_as_free_for_reuse Assertion failure can be triggered by some DDL executed under LOCK TABLES that holds lock for DDL target table multiple times (either explicitly or implcitly). When closing all table instances for given table (e.g. when preparing for table removal during CREATE OR REPLACE), only one instance was removed from m_locked_tables list. Later we attempt to re-insert one of the instances in mysql_create_table()/ add_back_last_deleted_lock(), which wasn't actually removed. This leads to m_locks_tables corruption, specifically loss of all following elements. Then UNLOCK TABLE won't reset some table instances properly (specifically pos_in_locked_tables), since they're not present in m_locked_tables. Eventually such table instance gets released to table cache and then re-used by subsequent statement, which triggers this assertion failure.
| | | | * | | Update contributorsIan Gilfillan2018-09-101-1/+3
| | | | | | |
| | | * | | | MDEV-16912: Spider Order By column[datatime] limit 5 returns 3 rowsJacob Mathew2018-09-132-0/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem occurs in 10.2 and earlier releases of MariaDB Server because the Partition Engine was not pushing the engine conditions to the underlying storage engine of each partition. This caused Spider to return the first 5 rows in the table with the data provided by the customer. 2 of the 5 rows did not qualify the WHERE clause, so they were removed from the result set by the server. To fix the problem, I have back-ported support for engine condition pushdown in the Partition Engine from MariaDB Server 10.3. Author: Jacob Mathew. Reviewer: Kentoku Shiba. Cherry-Picked: Commit eb2ca3d on branch bb-10.2-MDEV-16912
| | | * | | | MDEV-17155: Incorrect ORDER BY optimization: full index scan is used instead ↵Sergei Petrunia2018-09-121-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of range The bug was this scenario: 1. Join optimizer picks a range plan on index IDX1 (This index doesn't match the ORDER BY clause, so sorting will be needed) 2. Index Condition Pushdown pushes a part of WHERE down. The pushed condition is removed from SQL_SELECT::cond 3. test_if_skip_sort_order() figures that it's better to use IDX2 (as it will match ORDER BY ... LIMIT and so will execute faster) 3.1 It sees that there was a possible range access on IDX2. It tries to construct it by calling SQL_SELECT::test_quick_select(), but alas, SQL_SELECT::cond doesn't have all parts of WHERE anymore. So it uses full index scan which is slow. (The execution works fine because there's code further in test_if_skip_sort_order() which "Unpushes" the index condition and restores the original WHERE clause. It was just the test_quick_select call that suffered).
| | | * | | | MDEV-15845 Test failure on galera.galera_concurrent_ctasmkaruza2018-09-121-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | While executing CTAS galera applier thread can cause CTAS to abort and rollback. Rollback can take time causing applier thread to shutdown node after serial unsuccessful retries to apply transaction. Don't set lock_wait_timeout to zero to wait for lock.
| | * | | | | MDEV-13089 identifier quoting in partitioningSergei Golubchik2018-09-214-20/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | cover ALTER TABLE
| | * | | | | MDEV-16792 Assertion `m_status == DA_ERROR' failed in ↵Sergei Golubchik2018-09-211-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Diagnostics_area::sql_errno or wrong result upon SHOW TABLE STATUS after adding partition under ANSI_QUOTES if opening a table fails with a syntax error, the error shouldn't be suppressed completely as if it didn't happen at all.
| | * | | | | Remove an unused variableMarko Mäkelä2018-09-211-2/+0
| | | | | | |
| | * | | | | MDEV-17201 dropped anchor rows with non-null recursion queryIgor Babaev2018-09-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function st_select_lex_unit::exec_recursive() missed resetting of select_limit_cnt and offset_limit_cnt before execution of union parts. As a result recursive CTEs specified by UNIONs whose SELECTs contained LIMIT/OFFSET could return wrong sets of records.
| | * | | | | MDEV-17065 Crash on SHOW CREATE TABLE with CHECK CONSTRAINTMichael Widenius2018-09-161-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was that the original alias was replaced with a new allocated string, but constraint item's are still pointing to the original alias. Fixed by storing the original alias used when printing constraint in the tables mem_root.
| | * | | | | MDEV-16050 cte + geometry functions lead to crash.Alexey Botchkov2018-09-164-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Structures based on Gcalc_dyn_list need to be treated properly when copied in Item::get_copy().
| | * | | | | Fixed a compiler warning.Igor Babaev2018-09-151-1/+1
| | | | | | |
| | * | | | | MDEV-17154 Multiple selects from parametrized CTE fails with syntax errorIgor Babaev2018-09-148-20/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fills a serious flaw in the implementation of common table expressions. Before this patch an attempt to prepare a statement from a query with a parameter marker in a CTE that was used more than once in the query ended up with a bogus error message. Similarly if a statement in a stored procedure contained a CTE whose specification used a local variables and this CTE was referred to more than once in the statement then the server failed to execute the stored procedure returning a bogus error message on a non-existing field. The problems appeared due to incorrect handling of parameter markers / local variables in CTEs that were referred more than once. This patch fixes the problems by differentiating between the original occurrences of a parameter marker / local variable used in the specification of a CTE and the corresponding occurrences used in copies of this specification. These copies are substituted instead of non-first references to the CTE. The idea of the fix and even some code were taken from the MySQL implementation of the common table expressions.
| | * | | | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-1431-222/+570
| | |\ \ \ \ \ | | | |/ / / /
| | | * | | | Merge branch '10.0-galera' into 10.1Sergei Golubchik2018-09-0710-108/+232
| | | |\ \ \ \
| | | | * | | | MariaDB adjustments.Jan Lindström2018-08-031-3/+15
| | | | | | | |
| | | | * | | | Add missing WSREP(thd) condition and remove unnecessary DBUG_RETURN.Jan Lindström2018-08-021-3/+2
| | | | | | | |
| | | | * | | | Merge remote-tracking branch 'origin/5.5-galera' into 10.0-galeraJan Lindström2018-08-024-98/+145
| | | | |\ \ \ \
| | | | | * | | | Follow up to previous commit for codership/mysql-wsrep#332mariadb-galera-5.5.61Daniele Sciascia2018-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix misplaced `DBUG_RETURN` in `Alter_table_statement::execute`.
| | | | | * | | | Fix FK constraint violation in applier, after ALTER TABLE ADD FKDaniele Sciascia2018-08-024-118/+155
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adding a FK constraint to an existing table (ALTER TABLE ADD FOREIGN KEY) causes the applier to fail, if a concurrent DML statement that violate the new constraint (i.e. a DELETE or UPDATE of record in the parent table). For exmaple, the following scenario causes a crash in the applier: 1. ALTER successfully adds FK constraint in node_1 2. On node_2 is UPDATE is in pre_commit() and has certified successfully 3. ALTER is delivered in node_2 and BF aborts DML 4. Applying UPDATE event causes FK violation in node_1 To avoid this situation it is necessary for UPDATE to fail during certification. And for the UPDATE to fail certfication it is necessary that ALTER appends certification keys for both the child and the parent table. Before this patch, ALTER TABLE ADD FK only appended keys for child table which is ALTERed.
| | | | | * | | | Merge tag 'mariadb-5.5.61' into 5.5-galeraJan Lindström2018-08-0114-122/+303
| | | | | |\ \ \ \
| | | | * | \ \ \ \ Merge tag 'mariadb-10.0.36' into 10.0-galeraJan Lindström2018-08-0233-323/+611
| | | | |\ \ \ \ \ \
| | | | * | | | | | | MDEV-16799: Test wsrep.variables crash at sql_class.cc:639 thd_get_ha_dataJan Lindström2018-07-249-31/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that binlog_hton was not initialized fully when needed i.e. when wsrep_on = true.
| | | | * | | | | | | Fix compile error.Jan Lindström2018-07-191-1/+3
| | | | | | | | | | |
| | | | * | | | | | | MDEV-10564: Galera `wsrep_debug` patch logs MySQL user credentialsJan Lindström2018-07-191-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restricted output for CREATE USER, GRANT, REVOKE and SET PASSWORD so that it shows only above keywords but not rest of query i.e. not user or password.
| | | * | | | | | | | Merge branch '11.0' into 10.1Oleksandr Byelkin2018-09-0619-92/+316
| | | |\ \ \ \ \ \ \ \ | | | | | |_|_|_|/ / / | | | | |/| | | | | |
| | | | * | | | | | | MDEV-16465 Invalid (old?) table or database name or hang in ↵Sergei Golubchik2018-09-062-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys lowercase db and table names before prelocking. Post-fix for 9180e8666b8 This fixes failures on main.lowercase_table4 on Windows
| | | | * | | | | | | MDEV-16757 Memory leak after adding manually min/max statistical dataSergey Vojtovich2018-09-052-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for blob column Moved delete_stat_values_for_table_share() call to proper place.
| | | | * | | | | | | MDEV-16465 Invalid (old?) table or database name or hang in ↵Sergei Golubchik2018-09-044-9/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ha_innobase::delete_table and log semaphore wait upon concurrent DDL with foreign keys ALTER TABLE locks the table with TL_READ_NO_INSERT, to prevent the source table modifications while it's being copied. But there's an indirect way of modifying a table, via cascade FK actions. After previous commits, an attempt to modify an FK parent table will cause FK children to be prelocked, so the table-being-altered cannot be modified by a cascade FK action, because ALTER holds a lock and prelocking will wait. But if a new FK is being added by this very ALTER, then the target table is not locked yet (it's a temporary table). So, we have to lock FK parents explicitly.
View Lorry Controller Status