- 02 Jun, 2017 1 commit
-
-
Monty authored
- Changed warning to "'%-.192s.%-.192s' is not of type '%s'" to make the english a bit more correct
-
- 30 May, 2017 2 commits
-
-
Monty authored
Fixed the following things from the above MDEV: - Ensure the user has INSERT privilege when generating new sequence values with NEXT VALUE FOR or SETVAL() - Fixed bug in InnoDB when generating several sequence values in one statement - Ensure that read_set is up to date before calling ha_sequence::ha_write_row() - This is only a potential bug with storage engines that trusts the column maps completely
-
Monty authored
-
- 29 May, 2017 4 commits
-
-
Monty authored
-
Monty authored
This is needed for MyISAM and other storage engines which normally relies on THR_LOCK's to ensure that one is not writing the same block one could be reading from.
-
halfspawn authored
-
Alexander Barkov authored
-
- 27 May, 2017 7 commits
-
-
Alexander Barkov authored
The fix for MDEV-12866 fixed this problem as well. Adding tests only.
-
Alexander Barkov authored
Recent changes in Type_handler fixed this problem. Adding tests only.
-
Alexander Barkov authored
Adding tests for MDEV-9408 CREATE TABLE SELECT MAX(int_column) creates different columns for table vs view Recent fixes in Type_handler fixed this problem. Adding tests only.
-
Alexander Barkov authored
Adding tests for MDEV-9406 CREATE TABLE..SELECT creates different columns for IFNULL() and equivalent COALESCE,CASE,IF Recent changes in Type_handler fixed this problem as well. Adding tests only.
-
Alexander Barkov authored
Previous fixes in Type_handler (see the patch for MDEV-12875, MDEV-12886, MDEV-12916) fixed this problem as well. Adding only the test from the report.
-
Alexander Barkov authored
-
Alexander Barkov authored
Fixing to pass item->name.str rather than item->name to my_error().
-
- 26 May, 2017 2 commits
-
-
Alexander Barkov authored
-
Marko Mäkelä authored
row_search_mvcc(): Relax debug assertions. For NO_ROLLBACK tables, a transaction or a read view will not be started at the start of a statement. row_upd_clust_step(): Support CREATE TEMPORARY SEQUENCE or CREATE TEMPORARY TABLE…NO_ROLLBACK.
-
- 25 May, 2017 3 commits
-
-
Alexander Barkov authored
A cleanup for MDEV-11514, MDEV-11497, MDEV-11554, MDEV-11555 - IN and CASE type aggregation problems Removing cmp_item::get_comparator() and calling instead Type_handler::make_cmp_item(), which was earlier introduced by this patch: 74891ed2
-
Alexander Barkov authored
This is a joint patch fixing the following problems: MDEV-12875 Wrong VIEW column data type for COALESCE(int_column) MDEV-12886 Different default for INT and BIGINT column in a VIEW for a SELECT with ROLLUP MDEV-12916 Wrong column data type for an INT field of a cursor-anchored ROW variable All above problem happened because the global function ::create_tmp_field() called the top-level Item::create_tmp_field(), which made some tranformation for INT-result data types. For example, INT(11) became BIGINT(11), because 11 is a corner case and it's not known if it fits or does not fit into INT range, so Item::create_tmp_field() converted it to BIGINT(11) for safety. The main idea of this patch is to avoid such tranformations. 1. Fixing Item::create_tmp_field() not to have a special case for INT_RESULT. Item::create_tmp_field() is changed not to have a special case for INT_RESULT (which earlier made a decision based on Item's max_length). It now calls tmp_table_field_from_field_type() for INT_RESULT, therefore preserves the original data type (e.g. INT, YEAR) without conversion to BIGINT. This change is valid, because a number of recent fixes (e.g. in Item_func_int, Item_hybrid_func, Item_int, Item_splocal) guarantee that item->type_handler() now properly returns type_handler_long vs type_handler_longlong. So no adjustment by length is needed any more for Items returning INT_RESULT. After this change, Item::create_tmp_field() calls tmp_table_field_from_field_type() for all XXX_RESULT, except REAL_RESULT. 2. Fixing Item::create_tmp_field() not to have a special case for REAL_RESULT. Note, the reason for a special case for REAL_RESULT is to have a special constructor for Field_double(), forcing Field_real::not_fixed to be set to true. Taking into account that only Item_sum descendants actually need a special constructor call Field_double(not_fixed=true), not too loose precision when mixing individual rows to the aggregate result: - renaming Item::create_tmp_field() to Item_sum::create_tmp_field(). - changing Item::create_tmp_field() just to call tmp_table_field_from_field_type() for all XXX_RESULT types. A special case for REAL_RESULT in Item::create_tmp_field() is now gone. Item::create_tmp_field() is now symmetric for all XXX_RESULT types, and now just calls tmp_table_field_from_field_type(). 3. Fixing Item_func::create_field_for_create_select() not to have a special case for STRING_RESULT. After changes #1 and #2, the code in Item_func::create_field_for_create_select(), testing result_type(), becomes useless, because: now Item::create_tmp_field() and tmp_table_field_from_field_type() do exactly the same thing for all XXX_RESULT types for Item_func descendants: a. It calls tmp_table_field_from_field_type for STRING_RESULT directly. b. For other XXX_RESULT, it goes through Item::create_tmp_field(), which calls the global function ::create_tmp_field(), which calls item->create_tmp_field() for FUNC_ITEM, which calls tmp_table_field_from_field_type() again. So removing the virtual implementation of Item_func::create_field_for_create_select(). The inherited Item::create_field_for_create_select() now perfectly does the job, as it also calls tmp_table_field_from_field_type() for FUNC_ITEM, independently from XXX_RESULT type. 4. Taking into account #1 and #2, as well as some recent changes, removing virtual implementations: - Item_hybrid_func::create_tmp_field() - Item_hybrid_func::create_field_for_create_select() - Item_int_func::create_tmp_field() - Item_int_func::create_field_for_create_select() - Item_temporal_func::create_field_for_create_select() The derived versions from Item now perfectly work. 5. Moving a piece of code from create_tmp_field_from_item() to a new function create_tmp_field_from_item_finalize(), to reuse it in two places (see #6). 6. Changing the code responsible for BIT->INT/BIGIN tranformation (which is called for the cases when the created table, e.g. HEAP, does not fully support BIT) not to call create_tmp_field_from_item(), because the latter now calls tmp_table_field_from_field_type() instead of create_tmp_field() and thefore cannot do BIT transformation. So rewriting this code using a sequence of these calls: - item->type_handler_long_or_longlong() - handler->make_and_init_table_field() - create_tmp_field_from_item_finalize() 7. Miscelaneous changes: - Moving type_handler_long_or_longlong() from "protected" to "public", as it's now needed in the global function create_tmp_field(). 8. The above changes fixed MDEV-12875, MDEV-12886, MDEV-12916. So adding tests for these bugs.
-
Alexander Barkov authored
The fix for MDEV-12876 fixed this problem as well. So adding tests only.
-
- 24 May, 2017 5 commits
-
-
Monty authored
- Test with LOCK TABLES - Test mysqldump - Don't update rows for sequence tables if values doesn't change. This is needed as InnoDB gives an error for updates where values doesn't change.
-
Marko Mäkelä authored
Because SEQUENCE objects or NO_ROLLBACK tables do not support locking or MVCC or transactions, avoid starting a transaction. row_upd_step(): Do not start a transaction. Let the caller do that. que_thr_step(): Call trx_start_if_not_started_xa() for QUE_NODE_UPDATE. (The InnoDB SQL parser is not used for accessing NO_ROLLBACK tables.) row_ins_step(): Correct a too strict assertion and comment about concurrency. Multiple concurrent readers are allowed. row_update_for_mysql_using_upd_graph(): Do not start the transaction for NO_ROLLBACK tables. row_search_mvcc(): For NO_ROLLBACK tables, skip locking even inside LOCK TABLES. Only call trx_start_if_not_started() at the start of a statement, not for each individual request.
-
Monty authored
-
Monty authored
-
Alexander Barkov authored
-
- 23 May, 2017 4 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
The patch broke expressions like CAST(1.0e+300 AS SIGNED INT) in binary protocol, e.g.: mtr --ps cast Short real numbers like 1.0e+300 can return huge values, so using args[0]->max_length is not reliable to choose properly the result type for Item_func_signed and Item_func_unsigned (between INT and BIGINT). Setting Item_[un]signed_typecast::max_length to MAX_BIGINT_WIDTH when doing CAST from FLOAT/DOUBLE, to force type_handler() return &type_handler_longlong rather than &type_handler_long.
-
Monty authored
- Old sequence code forced row based replication for any statements that refered to a sequence table. What is new is that row based replication is now sequence aware: - NEXT VALUE is now generating a short row based event with only next_value and round being replicated. - Short row based events are now on the slave updated as trough SET_VALUE(sequence_name) - Full row based events are on the slave updated with a full insert, which is practically same as ALTER SEQUENCE. - INSERT on a SEQUENCE table does now a EXCLUSIVE LOCK to ensure that it is logged in binary log before any following NEXT VALUE calls. - Enable all sequence tests and fixed found bugs - ALTER SEQUENCE doesn't anymore allow changes that makes the next_value outside of allowed range - SEQUENCE changes are done with TL_WRITE_ALLOW_WRITE. Because of this one can generate a statement for MyISAM with both TL_WRITE_CONCURRENT_INSERT and TL_WRITE_ALLOW_WRITE. To fix a warning I had to add an extra test in thr_lock.c for this. - Removed UPDATE of SEQUENCE (no need to support this as we have ALTER SEQUENCE, which takes the EXCLUSIVE lock properly. - Removed DBUG_ASSERT() in MDL_context::upgrade_shared_lock. This was removed upstream in MySQL 5.6 in 72f823de453. - Simplified test in decided_logging_format() by using sql_command_flags() - Fix that we log DROP SEQUENCE correctly. - Fixed that Aria works with SEQUENCE
-
Alexander Barkov authored
Fixing a few problems with data type and metadata for INT result functions (MDEV-12852, MDEV-12853, MDEV-12869) This is a joint patch for: MDEV-12852 Out-of-range errors when CAST(1-2 AS UNSIGNED MDEV-12853 Out-of-range errors when CAST('-1' AS UNSIGNED MDEV-12869 Wrong metadata for integer additive and multiplicative operators 1. Fixing all Item_func_numhybrid descendants to set the precise data type handler (type_handler_long or type_handler_longlong) at fix_fields() time. This fixes MDEV-12869. 2. Fixing Item_func_unsigned_typecast to set the precise data type handler at fix_fields() time. This fixes MDEV-12852 and MDEV-12853. This is done by: - fixing Type_handler::Item_func_unsigned_fix_length_and_dec() and Type_handler_string_result::Item_func_unsigned_fix_length_and_dec() to properly detect situations when a negative epxression is converted to UNSIGNED. In this case, length of the result is now always set to MAX_BIGINT_WIDTH without trying to use args[0]->max_length, as very short arguments can produce very long result in such conversion: CAST(-1 AS UNSIGNED) -> 18446744073709551614 - adding a new virtual method "longlong Item::val_int_max() const", to preserve the old behavior for expressions like this: CAST(1 AS UNSIGNED) to stay under the INT data type (instead of BIGINT) for small positive integer literals. Using Item::unsigned_flag would not help, because Item_int does not set unsigned_flag to "true" for positive numbers. 3. Adding helper methods: * Item::type_handler_long_or_longlong() * Type_handler::type_handler_long_or_longlong() and reusing them in a few places, to reduce code duplication. 4. Making reorganation in create_tmp_field() and create_field_for_create_select() for Item_hybrid_func and descendants, to reduce duplicate code. They all now have a similar behavior in respect of creating fields. Only Item_func_user_var descendants have a different behavior. So moving the default behvior to Item_hybrid_func, and overriding behavior on Item_func_user_var level.
-
- 22 May, 2017 3 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
MDEV-12858 + MDEV+12859 + MDEV-12862 - a join patch fixing a few data type problems with CREATE..SELECT MDEV-12858 Out-of-range error for CREATE..SELECT unsigned_int_column+1 MDEV-12859 Out-of-range error for CREATE..SELECT @A:=EXTRACT(MINUTE_MICROSECOND FROM..) MDEV-12862 Data type of @A:=1e0 depends on the session character set 1. Moving a part of Item::create_tmp_field() into a new helper method Item::create_tmp_field_int() and reusing it in Item::create_tmp_field() and Item_func_signed::create_tmp_field(). Fixing the code in Item::create_tmp_field_int() to call Type_handler::make_table_field() instead of doing "new Field_long[long]" directly. This change revealed a problem reported in MDEV-12862. 2. Changing the "long vs longlong" cut-off length for - Item_func::create_tmp_field() - Item_sum::create_tmp_field() - Item_func_get_user_var::create_tmp_field() from MY_INT32_NUM_DECIMAL_DIGITS to (MY_INT32_NUM_DECIMAL_DIGITS - 2). This fixes MDEV-12858. After this change, the "convert_int_length" parameter to Item::create_tmp_field() is not needed any more, because (MY_INT32_NUM_DECIMAL_DIGITS - 2) is always passed. So removing the "convert_int_length" parameter. 3. Fixing Item::create_tmp_field() to pass max_char_length() instead of max_length to the constructor of Field_double(). This fixes MDEV-12862. 4. Additionally, fixing - Type_handler_{tiny|short|int24|long|longlong}::make_table_field() - Type_handler_{float|double}::make_table_field() to pass max_char_length() instead of max_length to Field contructors. This is needed by the change (1). 5. Adding new tests, and recording new correct results in the old tests in: - mysql-test/r/type_ranges.result - storage/tokudb/mysql-test/tokudb/r/type_ranges.result
-
Alexander Barkov authored
MDEV-12860 Out-of-range error on CREATE..SELECT with a view using MAX and EXTRACT(MINUTE_MICROSECOND..)
-
- 21 May, 2017 1 commit
-
-
Alexander Barkov authored
This is a joint patch for: MDEV-12856 Wrong result set metadata for DIV MDEV-12857 Out-of-range errors on CREATE..SELECT 2222222222 DIV 1
-
- 20 May, 2017 1 commit
-
-
Alexander Barkov authored
-
- 19 May, 2017 2 commits
-
-
Alexander Barkov authored
1. Adding the forgotten "SET sql_mode=STRICT_ALL_TABLES" into the test. 2. STRICT_ALL_TABLES revealed that CAST(0xFFFFFFFF AS SIGNED), e.g. with a hex number with 8 hex digits, did not work well. Fixing Item_func_unsigned::create_tmp_field() and Item_func_unsigned::create_field_for_create_select() to handle this corner case.
-
Alexander Barkov authored
-
- 18 May, 2017 2 commits
-
-
Alexander Barkov authored
-
halfspawn authored
-
- 17 May, 2017 3 commits
-
-
Alexander Barkov authored
MDEV-12833 Split Column_definition::create_length_to_internal_length() to virtual methods in Type_handler
-
Alexander Barkov authored
MDEV-12826 Add Type_handler::val_int_signed_typecast() and Type_handler::val_int_unsigned_typecast()
-
Alexander Barkov authored
- Adding new virtual methods in Type_handler: * Column_definition_prepare_stage1() * Column_definition_prepare_stage2() * calc_pack_length() - Using new methods to remove type specific code in: * Global function calc_pack_length() * Column_definition::prepare_create_field() * The loop body mysql_prepare_create_table() * Column_definition::sp_prepare_create_field()
-