summaryrefslogtreecommitdiff
path: root/sql
Commit message (Collapse)AuthorAgeFilesLines
* cleanup: mtr startup warningSergei Golubchik2017-02-141-1/+1
| | | | | | | options --log-slow-admin-statements, --log-queries-not-using-indexes and --log-slow-slave-statements have no effect if --log_slow_queries is not set 1. s/--log_slow_queries/--log-slow-queries/ 2. disable log-slow-admin-statement/etc in mytr when doing mysqld --help
* MDEV-11439 No data type JSON, but CAST(something AS JSON) pretends to workSergei Golubchik2017-02-147-57/+38
| | | | | | Use JSON_COMPACT(X) instead of CAST(X AS JSON). Bonus - X is validated to be a valid JSON. Fix a typo in the error message.
* bugfix: uninitialized variableSergei Golubchik2017-02-141-2/+1
| | | | fixes crashes on win32-debug
* MDEV-11439 No data type JSON, but CAST(something AS JSON) pretends toAlexey Botchkov2017-02-143-13/+86
| | | | | | work. json_detailed() fixed
* MDEV-11170: MariaDB 10.2 cannot start on MySQL 5.7 datadirVicențiu Ciorbaru2017-02-141-69/+149
| | | | | | PART 2 of the fix adds the logic of not using password column, unless it exists. If password column is missing we attempt to use plugin && authentication_string columns.
* MDEV-11170: MariaDB 10.2 cannot start on MySQL 5.7 datadirVicențiu Ciorbaru2017-02-142-463/+991
| | | | | | | | | | PART 1 of the fix requires a bit of refactoring to not use hard-coded field indices any more. Create classes that express the grant tables structure, without exposing the underlying field indices. Most of the code is converted to use these classes, except parts which are not directly affected by the MDEV-11170. These however are TODO items for subsequent refactoring.
* Define a helper class to allow for saving sql_mode using RAIIVicențiu Ciorbaru2017-02-142-19/+26
| | | | | On construction the Sql_mode_save class stores the current THD's sql_mode. On destruction, the THD's mode is restored.
* Allow READ_RECORD to make use of RAII and free itself on destructionVicențiu Ciorbaru2017-02-141-2/+6
|
* MDEV-11746: Wrong result upon using FIRST_VALUE with a window frameVicențiu Ciorbaru2017-02-141-5/+16
| | | | | | | The same approach is needed for LAST_VALUE, otherwise the LAST_VALUE sum functions are not cleared correctly. Now LAST_VALUE behaves as NTH_VALUE with 0 offset, only that the frame that it is examining is the bottom bound, not the top bound.
* MDEV-11746: Wrong result upon using FIRST_VALUE with a window frameVicențiu Ciorbaru2017-02-143-32/+17
| | | | | Reimplement FIRST_VALUE to act as NTH_VALUE with 0 offset. The previous implementation was flawed when the window frame would remove values.
* MDEV-10122: MariaDB does not support group functions in some contexts where ↵Vicențiu Ciorbaru2017-02-141-0/+3
| | | | | | | | | | | | | | | | | | MySQL does The problematic queries involve unions. For unions we have an optimization where we skip the ORDER BY clause in a query from one side of the union if it will be performed later due to UNION. EX: (SELECT a from t1 ORDER BY a) ORDER BY b; The first ordering by a is not necessary and it gets removed. The problem is that we still need to resolve the Items before removing the ORDER BY list from the SELECT_LEX structure. During this final resolve step however, we forgot to allow SET functions within the ORDER BY clause. This caused us to return an "Invalid use of group function" error during the checking performed by fix_fields in Item_sum::init_sum_func_check.
* Revert "MDEV-11439 No data type JSON, but CAST(something AS JSON) pretends ↵Sergei Golubchik2017-02-131-0/+1
| | | | | | | to work" This reverts commit 1f372cf1de2a15057a09c6936f025f09500c0228. Wasn't supposed to be pushed just yet.
* MDEV-11439 No data type JSON, but CAST(something AS JSON) pretends to workSergei Golubchik2017-02-131-1/+0
| | | | remove CAST(... AS JSON) from the grammar for 10.2.4
* MDEV-11704 InnoDB: Failing assertion: dfield_is_null(dfield2) || dfield2->dataSergei Golubchik2017-02-131-1/+1
| | | | | relax innodb assertion, because Field_blob::store() clearly says that a data pointer can be zero if the length is zero.
* MDEV-11604 Assertion `!check_datetime_range(ltime)' failed in ↵Sergei Golubchik2017-02-131-1/+4
| | | | TIME_to_longlong_datetime_packed
* MDEV-11582 InnoDB: Failing assertion: !((field)->vcol_info && ↵Sergei Golubchik2017-02-131-16/+38
| | | | | | | | !(field)->stored_in_db()) change the parser not to allow SERIAL as a normal data type. make a special rule for it, where it could be used for define fields, but not generated fields, not return type of a stored function, etc.
* bugfix: uninit variableSergei Golubchik2017-02-131-1/+1
|
* MDEV-11640 gcol.gcol_select_myisam fails in buildbot on PowerSergei Golubchik2017-02-133-18/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | JOIN_CACHE's were initialized in check_join_cache_usage() from make_join_readinfo(). After that make_join_readinfo() was looking whether it's possible to use keyread. Later, after make_join_readinfo(), optimizer decided whether to use filesort. And even later, at the execution time, from join_read_first(), keyread was actually enabled. The problem is, that if a query uses a vcol, base columns that it depends on are automatically added to the read_set - because they're needed to calculate the vcol. But if we're doing keyread, vcol is taken from the index, not calculated, and base columns do not need to be in the read set (even should not be - as they aren't getting values). The bug was that JOIN_CACHE used read_set with base columns, they were not read because of keyread, so it was caching garbage. So read_set is only known after the keyread was decided. And after the filesort was decided, as filesort doesn't use keyread. But check_join_cache_usage() needs to be done in make_join_readinfo(), as the code below depends on these checks, Fix: keep JOIN_CACHE checks where they were, but move initialization down to the very end of JOIN::optimize_inner. If keyread was enabled, update the read_set to include only columns that are part of the index. Copy the keyread logic from join_read_first() to happen at optimize time.
* support keyread in READ_RECORDSergei Golubchik2017-02-131-0/+12
| | | | | | | make init_read_record() to detect enabled keyread and use index_* access methods, not rnd_* this makes MariaDB to use keyread a lot more often than before
* cleanup: handler::key_readSergei Golubchik2017-02-139-44/+39
| | | | | | * rename to "keyread" (to avoid conflicts with tokudb), * change from bool to uint and store the keyread index number there * provide a bool accessor to check if keyread is enabled
* find_all_keys: add an assert, remove current_thdSergei Golubchik2017-02-132-13/+15
| | | | | | | | | | Filesort temporarily changes read_set to be tmp_set and marks only fields needed for filesort. Add an assert to ensure that it doesn't overwrite the old value of tmp_set, that is that read_set was *not* already tmp_set when filesort was invoked. Fix sql_update.cc that was was doing exactly that - changing read_set to tmp_set, configuring tmp_set for keyread, and then invoking filesort.
* cleanup: TABLE::mark_columns_used_by_index()Sergei Golubchik2017-02-137-32/+32
| | | | | | | | | mark_columns_used_by_index used to do reset + mark_columns_used_by_index_no_reset + start keyread + set bitmaps Now prepare_for_keyread does that, while mark_columns_used_by_index does only reset + mark_columns_used_by_index_no_reset, just as its name suggests.
* bugfix: don't calculate vcols if doing keyreadSergei Golubchik2017-02-131-1/+3
| | | | | | | | | | | | | old code didn't calculate vcols that were part of keyread, but calculated other vcols. It was wrong - there was no guarantee that vcol's base columns were part of keyread. Technically it's possible for the vcol not be a part of keyread, but all its base columns being part of keyread. But currently the optimizer doesn't do that, keyread is only used if it covers all columns used in the query. This fixes crashes of vcol.vcol_trigger_sp_innodb
* cleanup: remove TABLE::add_read_columns_used_by_indexSergei Golubchik2017-02-134-37/+6
| | | | | | | | | | | | | | | TABLE::add_read_columns_used_by_index() is conceptually wrong, it *adds* columns used by index to the bitmap, without clearing it first. But it also enables keyread, meaning that *only* columns from the index will be read. It is supposed to be used to add columns used by an index to a bitmap that already has columns of a primary key - for engines where a primary key is part of every index. The correct fix is to change mark_columns_used_by_index() to take into account extended keys. this reverts 1d0acc7754a44613d2ad and cf97cbd1db762c443aa3
* bugfix: TABLE::mark_columns_used_by_index_no_resetSergei Golubchik2017-02-131-6/+0
| | | | | it should not mark base columns that a vcol depends on, because keyread (on a vcol) will not read them
* cleanup: mark_columns_used_by_index_no_reset in handler::get_auto_incrementSergei Golubchik2017-02-133-15/+13
| | | | use table->mark_columns_used_by_index, don't copy it
* cleanup: mark_columns_used_by_index_no_reset in opt_range.ccSergei Golubchik2017-02-133-15/+10
| | | | use table->mark_columns_used_by_index, don't copy it
* bugfix: TABLE::mark_columns_used_by_indexSergei Golubchik2017-02-132-1/+7
| | | | | | Do *not* modify write_set. keyread only affects what columns are *read*, UPDATE statement can *write* into columns that aren't part of the keyread.
* cleanup: style fixes, sql_join_cache.ccSergei Golubchik2017-02-132-290/+285
|
* cleanup: TABLE::non_determinstic_insertSergei Golubchik2017-02-131-13/+2
| | | | move the check where it make sense, remove incorrect comment
* MDEV-10352 Server crashes in Field::set_default on CREATE TABLESergei Golubchik2017-02-131-3/+5
| | | | | fix Item_default_value not to pretend being const_item if the field's default_value expression isn't parsed yet
* MDEV-11836 vcol.vcol_keys_myisam fails in buildbot and outsideSergei Golubchik2017-02-1314-117/+88
| | | | | | | move TABLE::key_read into handler. Because in index merge and DS-MRR there can be many handlers per table, and some of them use key read while others don't. "keyread" is really per handler, not per TABLE property.
* MDEV-11784 View is created with invalid definition which causes ERROR 1241 ↵Sergei Golubchik2017-02-131-12/+10
| | | | | | (21000): Operand should contain 1 column(s) set the correct print precedence for IN subqueries
* Race condition in DEFAULT() with expressionsSergei Golubchik2017-02-131-8/+14
| | | | | Item_default_value::calculate was updating table->s->default_values, but it is supposed to be read-only
* MDEV-10201 Bad results for CREATE TABLE t1 (a INT DEFAULT b, b INT DEFAULT 4)Sergei Golubchik2017-02-136-18/+33
| | | | | | | | | | | | | Optionally do table->update_default_fields() even for INSERT that supposedly provides values for all column. Because these "values" might be DEFAULT, which would need table->update_default_fields() at the end. Also set Item_default_value::used_tables() from the default expression. Non-zero used_field() means that mysql_insert() will initialize all fields to their default values (with restore_record()) even if all columns are later provided with values. Because default expressions may refer to other columns and they must be initialized.
* Fixed bugs mdev-12051, mdev-10885.Igor Babaev2017-02-121-7/+15
| | | | | | | These are different bugs, but the fixing code is the same: if window functions are used over implicit grouping then now the execution should follow the general path calling the function set in JOIN::first_select.
* Merge branch 'bb-10.2-serg-merge' into 10.2Sergei Golubchik2017-02-1138-312/+315
|\
| * Merge branch '10.1' into 10.2Sergei Golubchik2017-02-1039-313/+316
| |\
| | * MDEV-11945: Fix description for "max_statement_time" in --helpNirbhay Choubey2017-01-311-2/+2
| | | | | | | | | | | | max_statement_time also applies to non-SELECT queries.
| | * MDEV-11817: Altering a table with more rows than ..Nirbhay Choubey2017-01-311-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | .. wsrep_max_ws_rows causes cluster to break when running Galera cluster in TOI mode Problem: While copying records to temporary table during ALTER TABLE, if there are more than wsrep_max_wsrep_rows records, the command fails. Fix: Since, the temporary table records are not placed into the binary log, wsrep_affected_rows must not be incremented. Added a test.
| | * MDEV-10812 WSREP causes responses being sent to protocol commandsSachin Setiya2017-01-311-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that must not send a response Problem:- When using wsrep (w/ galera) and issuing commands that can cause deadlocks, deadlock exception errors are sent in responses to commands such as close prepared statement and close connection which, by spec, must not send a response. Solution:- In dispatch_command, we will handle COM_QUIT and COM_STMT_CLOSE commands even in case of error. Patch Credit:- Jaka Močnik
| | * Merge 10.0 into 10.1Marko Mäkelä2017-01-261-1/+1
| | |\
| | | * MDEV-11108: Assertion `uniq_tuple_length_arg <= ↵Varun Gupta2017-01-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | table->file->max_key_length()' failed in SJ_TMP_TABLE::create_sj_weedout_tmp_table Removed the assert from the if clause to the else clause.
| | * | Revert "MDEV-7409 On RBR, extend the PROCESSLIST info to include at least ↵Sachin Setiya2017-01-251-63/+20
| | | | | | | | | | | | | | | | | | | | | | | | the name of the recently used table" This reverts commit 15f46d517435f3570e2c788349637a06d818a619.
| | * | MDEV-7409 On RBR, extend the PROCESSLIST info to include at least the name ↵Sachin Setiya2017-01-231-20/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | of the recently used table When RBR is used, add the db name to db Field and table name to Status Field of the "SHOW FULL PROCESSLIST" command for SQL thread.
| | * | MDEV-10232: Scalar result of subquery changes after adding an outer select stmtVarun Gupta2017-01-211-2/+3
| | | | | | | | | | | | | | | | | | | | In a subquery, we don't have to maintain order Added a fix such that order is considered when there is a limit clause.
| | * | Merge branch '10.0' into 10.1mariadb-10.1.21Sergei Golubchik2017-01-177-49/+19
| | |\ \ | | | |/
| | | * Merge branch '5.5' into 10.0Sergei Golubchik2017-01-177-51/+22
| | | |\
| | | | * bugfix: Item_func_min_max stored thd internallySergei Golubchik2017-01-152-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was used for get_datetime_value() and for thd->is_error(). But in fact, get_datetime_value() never used thd argument, because the cache ptr argument was NULL. And thd->is_error() check was not needed at that place at all.
| | | | * bugfix: cmp_item_row::alloc_comparators() allocated on the wrong arenaSergei Golubchik2017-01-154-27/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it used current_thd->alloc() and allocated on the thd's execution arena, not on table->expr_arena. Remove THD::arena_for_cached_items that is temporarily set in update_virtual_fields(), and replaces THD arena in get_datetime_value(). Instead set THD arena to table->expr_arena for the whole duration of update_virtual_fields()
View Lorry Controller Status