- 15 May, 2018 3 commits
-
-
Sachin Setiya authored
Fix mysql_load iterator to skip invisible fields.
-
Alexander Barkov authored
MDEV-16100 FOR SYSTEM_TIME erroneously resolves string user variables as transaction IDs Problem: Vers_history_point::resolve_unit() tested item->result_type() before item->fix_fields() was called. - Item_func_get_user_var::result_type() returned REAL_RESULT by default. This caused MDEV-16100. - Item_func_sp::result_type() crashed on assert. This caused MDEV-16094 Changes: 1. Adding item->fix_fields() into Vers_history_point::resolve_unit() before using data type specific properties of the history point expression. 2. Adding a new virtual method Type_handler::Vers_history_point_resolve_unit() 3. Implementing type-specific Type_handler_xxx::Type_handler::Vers_history_point_resolve_unit() in the way to: a. resolve temporal and general purpose string types to TIMESTAMP b. resolve BIT and general purpose INT types to TRANSACTION c. disallow use of non-relevant data type expressions in FOR SYSTEM_TIME Note, DOUBLE and DECIMAL data types are disallowed intentionally. - DOUBLE does not have enough precision to hold huge BIGINT UNSIGNED values - DECIMAL rounds on conversion to INT Both lack of precision and rounding might potentionally lead to very unpredictable results when a wrong transaction ID would be chosen. If one really wants dangerous use of DOUBLE and DECIMAL, explicit CAST can be used: FOR SYSTEM_TIME AS OF CAST(double_or_decimal AS UNSIGNED) QQ: perhaps DECIMAL(N,0) could still be allowed. 4. Adding a new virtual method Item::type_handler_for_system_time(), to make HEX hybrids and bit literals work as TRANSACTION rather than TIMESTAMP. 5. sql_yacc.yy: replacing the rule temporal_literal to "TIMESTAMP TEXT_STRING". Other temporal literals now resolve to TIMESTAMP through the new Type_handler methods. No special grammar needed. This removed a few shift/resolve conflicts. (TIMESTAMP related conflicts in "history_point:" will be removed separately) 6. Removing the "timestamp_only" parameter from vers_select_conds_t::resolve_units() and Vers_history_point::resolve_unit(). It was a hint telling that a table did not have any TRANSACTION-aware system time columns, so it's OK to resolve to TIMESTAMP in case of uncertainty. In the new reduction it works as follows: - the decision between TIMESTAMP and TRANSACTION is first made based only on the expression data type only - then, in case if the expression resolved to TRANSACTION, the table is checked if TRANSACTION-aware columns really exist. This way is safer against possible ALTER TABLE statements changing ROW START and ROW END columns from "BIGINT UNSIGNED" to "TIMESTAMP(x)" or the other way around.
-
Igor Babaev authored
-
- 14 May, 2018 7 commits
-
-
Jacob Mathew authored
This problem occured because the reorganization of the list of values when the number of elements exceeds 32 was not handled correctly. I have fixed the problem by fixing the way that the list values are reorganized when the number of list values exceeds 32. Author: Jacob Mathew. Reviewer: Alexey Botchkov. Merged From: Branch bb-10.3-MDEV-16101
-
Igor Babaev authored
Forced columns of recursive CTEs to be nullable. SQL standard requires this only from recursive columns, but in our code so far we do not differentiate between recursive and non-recursive columns when aggregating types of the union that specifies a recursive CTE.
-
Jacob Mathew authored
This problem occured because the reorganization of the list of values when the number of elements exceeds 32 was not handled correctly. I have fixed the problem by fixing the way that the list values are reorganized when the number of list values exceeds 32. Author: Jacob Mathew. Reviewer: Alexey Botchkov.
-
Alexander Barkov authored
-
Michael Widenius authored
Problem was that we used table->s->db_type() for accessing handlerton of opened file instead of table->file->ht Other bug fixed: - Ensure that we set error if reopen_tables() fails (This was the cause of assert)
-
Michael Widenius authored
-
Michael Widenius authored
-
- 12 May, 2018 27 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
The predicate dict_table_is_discarded() checks whether ALTER TABLE…DISCARD TABLESPACE has been executed. Replace most occurrences of dict_table_is_discarded() with checks of dict_table_t::space. A few checks for the flag DICT_TF2_DISCARDED are necessary; write them inline. Because !is_readable() implies !space, some checks for dict_table_is_discarded() were redundant.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Sergei Golubchik authored
-
Eugene Kosov authored
Fixed by using exactly the same filtering conditions as specified by standard in 7.6 <table reference> General Rules
-
Aleksey Midenkov authored
MDEV-14823 Wrong error message upon selecting from a system_time partition MDEV-15956 Strange ER_UNSUPPORTED_ACTION_ON_GENERATED_COLUMN upon ALTER on versioning column
-
Aleksey Midenkov authored
MDEV-16043 Assertion thd->Item_change_list::is_empty() failed in mysql_parse upon SELECT from a view reading from a versioned table Lost restore_active_arena(). Using of Query_arena_stmt is suggested instead.
-
Sergei Golubchik authored
-
Aleksey Midenkov authored
Store transaction start time in thd->transaction.start_time. THD::transaction_time() wraps over transaction.start_time taking into account current status of BEGIN.
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Eugene Kosov authored
-
Eugene Kosov authored
-
Sergei Golubchik authored
Don't use hidden system time in versioning, but keep the system time logic in THD to workaround low-res system clock and replication not versioned to versioned. This reverts MDEV-14788 (System versioning cannot be based on local timestamps, as it is now). Versioning is based on local timestamps again, but timestamps are protected by MDEV-15923 (option to control who can set session @@timestamp).
-
Sergei Golubchik authored
--secure-timestamp=NO|SUPER|REPLICATION|YES
-
Sergei Golubchik authored
remove the redundant declaration tail
-
Sergei Golubchik authored
-
Sergei Golubchik authored
this is always enabled now, no need for a conditional
-
Sergei Golubchik authored
-
Sergei Golubchik authored
rename LString/XString classes, remove unused ones
-
Sergei Golubchik authored
Make sure that SELECT_LEX_UNIT::derived, behaves as documented (points to the "TABLE_LIST representing this union in the embedding select"). For recursive CTE this was not necessarily the case, it could've pointed to the TABLE_LIST inside the CTE, not in the embedding select. To fix: * don't update unit->derived in mysql_derived_prepare(), pass derived as an argument to st_select_lex_unit::prepare() * prefer to set unit->derived in TABLE_LIST::init_derived() to the TABLE_LIST in the embedding select, not to the recursive reference. Fail if there are many TABLE_LISTs in the embedding select with conflicting FOR SYSTEM_TIME clauses. cleanup: * remove redundant THD* argument from st_select_lex_unit::prepare()
-
Sergei Golubchik authored
it's internal storage engine error, don't let it leak into the upper layer.
-
Sergei Golubchik authored
Make --gdb to take an optional argument *only* if it's written after '=', not after a space. followup for 339b9055
-
Sergei Golubchik authored
-
Marko Mäkelä authored
In InnoDB, CREATE TEMPORARY TABLE does not allow FULLTEXT INDEX. Replace a condition with a debug assertion, and add a test.
-
Marko Mäkelä authored
-
- 11 May, 2018 3 commits
-
-
Marko Mäkelä authored
-
Sachin Agarwal authored
Problem: Fix for Bug #21348684 (#Rb9581) introduced a conditional debug execute 'buf_pool_resize_chunk_null', which causes new chunks memory for 2nd buffer pool instance is freed. Buffer pool resize function removes all old chunks entry from 'buf_chunk_map_reg' and add new chunks entry into it. But when 'buf_pool_resize_chunk_null' is set true, 2nd buffer pool instance's chunk entries are not added into 'buf_chunk_map_reg'. When purge thread tries to access that buffer chunk, it leads to debug assertion. Fix: Added old chunk entries into 'buf_chunk_map_reg' for 2nd buffer pool instance when 'buf_pool_resize_chunk_null' debug condition is set to true. Reviewed by: Jimmy <Jimmy.Yang@oracle.com> RB: 18664
-
Aakanksha Verma authored
PROBLEM Issue found during ntest run is a regression of Bug #27141613. The issue is basically when index is being freed due to an error during its creation,when the index isn't added to dictionary cache its field columns are not set, the derefrencing of null col pointer during the clean of index from the virtual column's leads to a crash. NOTE: Also test i_innodb.virtual_debug was failing on 32k page size and above for the newly added scenario. Fixed that. FIX Added a check that if only the index is cached , the virtual index freeing from the virtual cols index list is performed. Reviewed by: Satya Bodapati<satya.bodapati@oracle.com> RB: 18670
-