mariadb

Commit Graph

Author	SHA1	Message	Date
Alexander Barkov	b915f79e4e	MDEV-25904 New collation functions to compare InnoDB style trimmed NO PAD strings	4 years ago
Aleksey Midenkov	911c803db1	MDEV-22660 System versioning cleanups - Cleaned up Vers_parse_info::check_sys_fields(); - Renamed VERS_SYS_START_FLAG, VERS_SYS_END_FLAG to VERS_ROW_START, VERS_ROW_END.	4 years ago
Michael Widenius	497b694936	Fixed compile errors when compiling with HAVE_valgrind	4 years ago
Aleksey Midenkov	160d97a4aa	MDEV-18734 ASAN heap-use-after-free upon sorting by blob column from partitioned table ha_partition stores records in array of m_ordered_rec_buffer and uses it for prio queue in ordered index scan. When the records are restored from the array the blob buffers may be already freed or rewritten. The solution is to take temporary ownership of cached blob buffers via String::swap(). When the record is restored from m_ordered_rec_buffer the ownership is returned to table fields. Cleanups: init_record_priority_queue(): removed needless !m_ordered_rec_buffer check as there is same assertion few lines before. dbug_print_row() for arbitrary row pointer	4 years ago
Nikita Malyavin	0e9ba176bf	MDEV-17890 Server crash on DELETE with YEAR field with truncated expr The failing reason was inconsistent truncation rules: the value of virtual column could have been evaluated to '2000' sometimes instead of '0000' for value 'a'. The reason why `c YEAR AS ('aaaa')` was not evaluated same is that len=4 is a special case insidew Field_year::store. The correct fix is: always evaluate a bad value to 0000 instead 2000. The truncated values should be evaluated as usual. $support_virtual_index is finally changed to 1 in gcol.gcol_ins_upd_innodb, which is also enough for testing. The test from original bug report is also added.	5 years ago
Monty	fa0bbff032	Fixed that compile-pentium64-valgrind-max works - Removed Tokudb (no need to test this anymore with valgrind) - Added __attribute__(unused)) to a few places to be able to compile even if valgrind/memcheck.h is not installed. Reviewer: Marko Mäkelä <marko.makela@mariadb.com>	5 years ago
Alexander Barkov	58780b5afb	MDEV-22775 [HY000][1553] Changing name of primary key column with foreign key constraint fails. Problem: The problem happened because of a conceptual flaw in the server code: a. The table level CHARSET/COLLATE clause affected all data types, including numeric and temporal ones: CREATE TABLE t1 (a INT) CHARACTER SET utf8 [COLLATE utf8_general_ci]; In the above example, the Column_definition_attributes (and then the FRM record) for the column "a" erroneously inherited "utf8" as its character set. b. The "ALTER TABLE t1 CONVERT TO CHARACTER SET csname" statement also erroneously affected Column_definition_attributes::charset for numeric and temporal data types and wrote "csname" as their character set into FRM files. So now we have arbitrary non-relevant charset ID values for numeric and temporal data types in all FRM files in the world :) The code in the server and the other engines did not seem to be affected by this flaw. Only InnoDB inplace ALTER was affected. Solution: Fixing the code in the way that only character string data types (CHAR,VARCHAR,TEXT,ENUM,SET): - inherit the table level CHARSET/COLLATE clause - get the charset value according to "CONVERT TO CHARACTER SET csname". Numeric and temporal data types now always get &my_charset_numeric in Column_definition_attributes::charset and always write its ID into FRM files: - no matter what the table level CHARSET/COLLATE clause is, and - no matter what "CONVERT TO CHARACTER SET" says. Details: 1. Adding helper classes to pass small parts of HA_CREATE_INFO into Type_handler methods: - Column_derived_attributes - to pass table level CHARSET/COLLATE, so columns that do not have explicit CHARSET/COLLATE clauses can derive them from the table level, e.g. CREATE TABLE t1 (a VARCHAR(1), b CHAR(1)) CHARACTER SET utf8; - Column_bulk_alter_attributes - to pass bulk attribute changes generated by the ALTER related code. These bulk changes affect multiple columns at the same time: ALTER TABLE ... CONVERT TO CHARACTER SET csname; Note, passing the whole HA_CREATE_INFO directly to Type_handler would not be good: HA_CREATE_INFO is huge and would need not desired dependencies in sql_type.h and sql_type.cc. The Type_handler API should use smallest possible data types! 2. Type_handler::Column_definition_prepare_stage1() is now responsible to set Column_definition::charset properly, according to the data type, for example: - For string data types, Column_definition_attributes::charset is set from the table level CHARSET/COLLATE clause (if not specified explicitly in the column definition). - For numeric and temporal fields, Column_definition_attributes::charset is set to &my_charset_numeric, no matter what the table level CHARSET/COLLATE says. - For GEOMETRY, Column_definition_attributes::charset is set to &my_charset_bin, no matter what the table level CHARSET/COLLATE says. Previously this code (setting `charset`) was outside of of Column_definition_prepare_stage1(), namely in mysql_prepare_create_table(), and was erroneously called for all data types. 3. Adding Type_handler::Column_definition_bulk_alter(), to handle "ALTER TABLE .. CONVERT TO". Previously this code was inside get_sql_field_charset() and was erroneously called for all data types. 4. Removing the Schema_specification_st parameter from Type_handler::Column_definition_redefine_stage1(). Column_definition_attributes::charset is now fully properly initialized by Column_definition_prepare_stage1(). So we don't need access to the table level CHARSET/COLLATE clause in Column_definition_redefine_stage1() any more. 5. Other changes: - Removing global function get_sql_field_charset() - Moving the part of the former get_sql_field_charset(), which was responsible to inherit the table level CHARSET/COLLATE clause to new methods: -- Column_definition_attributes::explicit_or_derived_charset() and -- Column_definition::prepare_charset_for_string(). This code is only needed for string data types. Previously it was erroneously called for all data types. - Moving another part, which was responsible to apply the "CONVERT TO" clause, to Type_handler_general_purpose_string::Column_definition_bulk_alter(). - Replacing the call for get_sql_field_charset() in sql_partition.cc to sql_field->explicit_or_derived_charset() - it is perfectly enough. The old code was redundant: get_sql_field_charset() was called from sql_partition.cc only when there were no a "CONVERT TO CHARACTER SET" clause involved, so its purpose was only to inherit the table level CHARSET/COLLATE clause. - Moving the code handling the BINCMP_FLAG flag from mysql_prepare_create_table() to Column_definition::prepare_charset_for_string(): This code is responsible to resolve the BINARY comparison style into the corresponding _bin collation, to do the following transparent rewrite: CREATE TABLE t1 (a VARCHAR(10) BINARY) CHARSET utf8; -> CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_bin); This code is only needed for string data types. Previously it was erroneously called for all data types. 6. Renaming Table_scope_and_contents_source_pod_st::table_charset to alter_table_convert_to_charset, because the only purpose it's used for is handlering "ALTER .. CONVERT". The new name is much more self-descriptive.	5 years ago
Nikita Malyavin	21809f9a45	MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failed The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_, all_set bitmaps are never substituted already. This patch changes the following function prototypes: tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps.	5 years ago
Nikita Malyavin	e25623e78a	MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failed The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_, all_set bitmaps are never substituted already. This patch changes the following function prototypes: tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps.	5 years ago
Sergei Golubchik	f6e91552f0	MDEV-4677 GROUP_CONCAT not showing any output with group_concat_max_len >= 4Gb don't allow group_concat_max_len values >= 4Gb (they never worked anyway)	5 years ago
Sergei Golubchik	00f54b56b1	cleanup: RAII helper for changing thd->count_cuted_rows	5 years ago
Marko Mäkelä	8036d0a359	MDEV-22387: Do not violate __attribute__((nonnull)) This follows up commit commit `94a520ddbe` and commit `7c5519c12d`. After these changes, the default test suites on a cmake -DWITH_UBSAN=ON build no longer fail due to passing null pointers as parameters that are declared to never be null, but plenty of other runtime errors remain.	5 years ago
Alexander Barkov	04ce29354b	MDEV-23551 Performance degratation in temporal literals in 10.4 Problem: Queries like this showed performance degratation in 10.4 over 10.3: SELECT temporal_literal FROM t1; SELECT temporal_literal + 1 FROM t1; SELECT COUNT() FROM t1 WHERE temporal_column = temporal_literal; SELECT COUNT() FROM t1 WHERE temporal_column = string_literal; Fix: Replacing the universal member "MYSQL_TIME cached_time" in Item_temporal_literal to data type specific containers: - Date in Item_date_literal - Time in Item_time_literal - Datetime in Item_datetime_literal This restores the performance, and make it even better in some cases. See benchmark results in MDEV. Also, this change makes futher separations of Date, Time, Datetime from each other, which will make it possible not to derive them from a too heavy (40 bytes) MYSQL_TIME, and replace them to smaller data type specific containers.	5 years ago
Alexander Barkov	2e5d86f49e	MDEV-23537 Comparison with temporal columns is slow in MariaDB Implementing methods: - Field::val_time_packed() - Field::val_datetime_packed() - Item_field::val_datetime_packed(THD thd); - Item_field::val_time_packed(THD thd); to give a faster access to temporal packed longlong representation of a Field, which is used in temporal Arg_comparator's to DATE, TIME, DATETIME data types. The same idea is used in MySQL-5.6+. This improves performance.	5 years ago
Alexander Barkov	ae33ebe5b3	MDEV-23525 Wrong result of MIN(time_expr) and MAX(time_expr) with GROUP BY 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)	5 years ago
Alexander Barkov	d63631c3fa	MDEV-19632 Replication aborts with ER_SLAVE_CONVERSION_FAILED upon CREATE ... 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.	5 years ago
Nikita Malyavin	fd0abc890f	MDEV-18042 Server crashes upon adding a non-null date column under NO_ZERO_DATE with ALGORITHM=INPLACE accept table_name and db_name instead of table_share in make_truncated_value_warning	5 years ago
Sergei Golubchik	0b5b2f8641	Bug #25207522 : INCORRECT ORDER-BY BEHAVIOR ON A PARTITIONED TABLE WITH A COMPOSITE PREFIX INDEX Fix prefix key comparison in partitioning. Comparions must take into account no more than prefix_len characters. It used to compare prefix_len*mbmaxlen bytes.	5 years ago
Alexander Barkov	29851b677e	MDEV-23282 FLOAT(53,0) badly handles out-of-range values truncate_double() did not take into account the max_value limit in case when dec<NOT_FIXED_DEC.	5 years ago
Ian Gilfillan	d2982331a6	Code comment spellfixes	5 years ago
Oleksandr Byelkin	a759f9af51	Fix typo in the comment (and old info)	5 years ago
Monty	65f831d17c	Fixed bugs found by valgrind - Some of the bug fixes are backports from 10.5! - The fix in innobase/fil/fil0fil.cc is just a backport to get less error messages in mysqld.1.err when running with valgrind. - Renamed HAVE_valgrind_or_MSAN to HAVE_valgrind	6 years ago
Monty	29f9e679ad	Don't copy uninitialized bytes when copying varstrings When using field_conv(), which is called in case of field1=field2 copy in fill_records(), full varstring's was copied, including unitialized bytes. This caused valgrind to compilain about usage of unitialized bytes when using Aria static length records. Fixed by not using memcpy when copying varstrings but instead just copy the real bytes.	6 years ago
Varun Gupta	4c3cbe2392	MDEV-22665: Print ranges in the optimizer trace created for non-indexed columns when optimizer_use_condition_selectivity >2 Now the optimizer trace shows the ranges constructed while getting estimates from EITS	6 years ago
Alexander Barkov	86c50a255a	MDEV-22734 Assertion `mon > 0 && mon < 13' failed in sec_since_epoch When processing a condition like: WHERE timestamp_column='2010-00-01 00:00:00' don't replace the constant to Item_datetime_literal if the constant it has zeros (in the month or in the day).	6 years ago
Varun Gupta	f30ff10c8d	MDEV-22715: SIGSEGV in radixsort_for_str_ptr and in native_compare/my_qsort2 (optimized builds) For DECIMAL[(M[,D])] datatype max_sort_length was not being honoured which was leading to buffer overflow while making the sort key. The fix to this problem would be to create sort keys for decimals with atmost max_sort_key bytes Important: The minimum value of max_sort_length has been raised to 8 (previously was 4), so fixed size datatypes like DOUBLE and BIGINIT are not truncated for lower values of max_sort_length.	6 years ago
Aleksey Midenkov	57f7b4866f	MDEV-16937 Strict SQL with system versioned tables causes issues (10.4) Respect system fields in NO_ZERO_DATE mode. This is the subject for refactoring in MDEV-19597 Conflict resolution from `7d52233107`	6 years ago
Aleksey Midenkov	19da9a51ae	MDEV-16937 Strict SQL with system versioned tables causes issues Respect system fields in NO_ZERO_DATE mode. This is the subject for refactoring in MDEV-19597	6 years ago
Marko Mäkelä	ff66d65a09	Amend af784385b4a2b286000fa2c658e34283fe7bba60: Avoid vtable overhead When neither MSAN nor Valgrind are enabled, declare Field::mark_unused_memory_as_defined() as an empty inline function, instead of declaring it as a virtual function.	6 years ago
Aleksey Midenkov	a4996f951d	MDEV-22563 Segfault on duplicate free of Item_func_in::array Same array instance in two Item_func_in instances. First Item_func_in instance is freed on table close. Second one is freed on cleanup_after_query(). get_copy() depends on copy ctor for copying an item and hence does shallow copy for default copy ctor. Use build_clone() for deep copy of Item_func_in.	6 years ago
Monty	af784385b4	Fix for using uninitialized memory MDEV-22073 MSAN use-of-uninitialized-value in collect_statistics_for_table() Other things: innodb.analyze_table was changed to mainly test statistic collection. Was discussed with Marko.	6 years ago
Monty	277aa85c9b	Fixed bugs found by valgrind Other things: - Removed innodb_encryption_tables.test from valgrind as it takes a REALLY long time	6 years ago
Monty	48eda61cd4	Fixed memory leak with DEFAULT(f) on Geometry field MDEV-21056 Assertion `global_status_var.global_memory_used == 0' failed upon shutdown after query with DEFAULT on a geometry field	6 years ago
Aleksey Midenkov	76063c2a13	MDEV-20494 ER_NOT_FORM_FILE or assertion upon adding partition to period table - Fixed mysql_prepare_create_table() constraint duplicate checking; - Refactored period constraint handling in mysql_prepare_alter_table(): * No need to allocate new objects; * Keep old constraint name but exclude it from dup checking by automatic_name; - Some minor memory leaks fixed; - Some conceptual TODOs.	6 years ago
Marko Mäkelä	fd5c36bed5	MDEV-21959: Fix a type mismatch on 64-bit systems	6 years ago
Alexey Botchkov	e64a3df4dc	MDEV-21959 GIS error message doesn't show the wrong value, just the type. Error message now shows the whole value.	6 years ago
Vlad Lesin	6718d3bc32	MDEV-21082: isnan/isinf compilation errors, isfinite warnings on MacOS The fix consists of three commits backported from 10.3: 1) Cleanup isnan() portability checks (cherry picked from commit `7ffd7fe962`) 2) Cleanup isinf() portability checks Original problem reported by Wlad: re-compilation of 10.3 on top of 10.2 build would cache undefined HAVE_ISINF from 10.2, whereas it is expected to be 1 in 10.3. std::isinf() seem to be available on all supported platforms. (cherry picked from commit `bc469a0bdf`) 3) Use std::isfinite in C++ code This is addition to parent revision fixing build failures. (cherry picked from commit `54999f4e75`)	8 years ago
Varun Gupta	ab9f378b0b	Backporting `273d8eb12c` Proper fix for disabling warnings in read_statistics_for_table()	6 years ago
Michael Widenius	e157f81771	Remove Field::is_stat_field completely	6 years ago
Michael Widenius	1bbe8c5e0f	Proper fix for disabling warnings in read_statistics_for_table(). MDEV-20589: Server still crashes in Field::set_warning_truncated_wrong_value - Use dbug_tmp_use_all_columns() to mark that all fields can be used - Remove field->is_stat_field (not needed) - Remove extra arguments to Field::clone() that should not be there - Safety fix for Field::set_warning_truncated_wrong_value() to not crash if table is zero in production builds (We have got crashes several times here so better to be safe than sorry). - Threat wrong character string warnings identical to other field conversion warnings. This removes some warnings we before got from internal conversion errors. There is no good reason why a user would get an error in case of 'key_field='wrong-utf8-string' but not for 'field=wrong-utf8-string'. The old code could also easily give thousands of no-sence warnings for one single statement.	6 years ago
Varun Gupta	273d8eb12c	MDEV-20589: Server still crashes in Field::set_warning_truncated_wrong_value The flag is_stat_field is not set for the min_value and max_value of field items inside table share. This is a must requirement as we don't want to throw warnings of truncation when we read values from the statistics table to the column statistics of table share fields.	6 years ago
Alexander Barkov	c924e39fab	MDEV-18153 Assertion `0' or Assertion `btr_validate_index(index, 0)' failed in row_upd_sec_index_entry or error code 126: Index is corrupted upon UPDATE with TIME_ROUND_FRACTIONAL Conversion to a temporal data type resulting into a lower precision depends on TIME_ROUND_FRACTIONAL. Taking into account this dependency in: - indexed generated virtual column expressions - persistent virtual column expressions A warning is now issued if conversion from the generation expression to the column data type depends on TIME_ROUND_FRACTIONAL. The warning will be changed to error in 10.5	6 years ago
Sergei Golubchik	8dca4cf53f	MDEV-20403 Assertion `0' or Assertion `btr_validate_index(index, 0)' failed in row_upd_sec_index_entry or error code 126: Index is corrupted upon UPDATE with TIMESTAMP..ON UPDATE remove a special treatment of a bare DEFAULT keyword that made it behave inconsistently and differently from DEFAULT(column). Now all forms of the explicit assignment of a default column value behave identically, and all count as an explicitly assigned value (for the purpose of ON UPDATE NOW). followup for `c7c481f4d9`	6 years ago
Alexander Barkov	ef00ac4c86	Part2: MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH This patch allows the server to open old tables that have "bad" generated columns (i.e. indexed virtual generated columns, persistent generated columns) that depend on sql_mode, for general things like SELECT, INSERT, DROP, etc. Warning are issued in such cases. Only these commands are now disallowed and return an error: - CREATE TABLE introducing a "bad" generated column - ALTER TABLE introducing a "bad" generated column - CREATE INDEX introdicing a "bad" generated column (i.e. adding an index on a virtual generated column that depends on sql_mode). Note, these commands are allowed: - ALTER TABLE removing a "bad" generate column - ALTER TABLE removing an index from a "bad" virtual generated column - DROP INDEX removing an index from a "bad" virtual generated column but only if the table does not have any "bad" columns as a result.	6 years ago
Alexander Barkov	dc719597ee	MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH This change takes into account a column's GENERATED ALWAYS AS expression dependcy on sql_mode's PAD_CHAR_TO_FULL_LENGTH and NO_UNSIGNED_SUBTRACTION flags. Indexed virtual columns as well as persistent generated columns are now not allowed to have such dependencies to avoid inconsistent data or index files on sql_mode changes. So an error is now returned in cases like this: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (a) PERSISTENT -- CHAR->VARCHAR or CHAR->TEXT = ERROR ); Functions RPAD() and RTRIM() can now remove dependency on PAD_CHAR_TO_FULL_LENGTH. So this can be used instead: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (RTRIM(a)) PERSISTENT ); Note, unlike CHAR->VARCHAR and CHAR->TEXT this still works, not RPAD(a) is needed: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v CHAR(5) AS (a) PERSISTENT -- CHAR->CHAR is OK ); More sql_mode flags may affect values of generated columns. They will be addressed separately. See comments in sql_mode.h for implementation details.	6 years ago
Sujatha	e7b71e0daa	MDEV-19925: Column ... cannot be converted from type 'varchar(20)' to type 'varchar(20)' Cherry picking: Bug#25135304: RBR: WRONG FIELD LENGTH IN ERROR MESSAGE commit `47bd3f7cf3` Description: ============ In row based replication, when replicating from a table with a field with character set set to UTF8mb3 to the same table with the same field set to character set UTF8mb4 I get a confusing error message: For VARCHAR: VARCHAR(1) 'utf8mb3' to VARCHAR(1) 'utf8mb4' "Column 0 of table 'test.t1' cannot be converted from type 'varchar(3)' to type 'varchar(1)'" Similar issue with CHAR type as well. Issue with respect to BLOB types: For BLOB: LONGBLOB to TINYBLOB - Error message displays incorrect blob type. "Column 0 of table 'test.t1' cannot be converted from type 'tinyblob' to type 'tinyblob'" For BINARY to BINARY - Error message displays incorrect type for master side field. "Column 0 of table 'test.t' cannot be converted from type 'char(1)' to type 'binary(10)'" Similar issue exists for VARBINARY type. It is displayed as 'VARCHAR'. Analysis: ========= In Row based replication charset information is not sent as part of metadata from master to slave. For VARCHAR field its character length is converted into equivalent octets/bytes and stored internally. At the time of displaying the data to user it is converted back to original character length. For example: VARCHAR(2)- utf8mb3 is stored as:2*3 = VARCHAR(6) At the time of displaying it to user VARCHAR(6)- charset utf8mb3:6/3= VARCHAR(2). At present the internally converted octect length is sent from master to slave with out providing the charset information. On slave side if the type conversion fails 'show_sql_type' function is used to get the type specific information from metadata. Since there is no charset information is available the filed type is displayed as VARCHAR(6). This results in confused error message. For CHAR fields CHAR(1)- utf8mb3 - CHAR(3) CHAR(1)- utf8mb4 - CHAR(4) 'show_sql_type' function which retrieves type information from metadata uses (bytes/local charset length) to get actual character length. If slave's chaset is 'utf8mb4' then CHAR(3/4)-->CHAR(0) CHAR(4/4)-->CHAR(1). This results in confused error message. Analysis for BLOB type issue: BLOB's length is represented in two forms. 1. Actual length i.e (length < 256) type= MYSQL_TYPE_TINY_BLOB; (length < 65536) type= MYSQL_TYPE_BLOB; ... 2. packlength - The number of bytes used to represent the length of the blob 1- tinyblob 2- blob ... In row based replication only the packlength is written in the binary log. On the slave side this packlength is interpreted as actual length of the blob. Hence the length is always < 256 and the type is displayed as tiny blob. Analysis for BINARY to BINARY type issue: The character set information is needed to identify a filed's type as char or binary. Since master side character set information is not available on the slave side both binary and char fields are displayed as char. Fix: === For CHAR and VARCHAR fields display their length in octets for both source and target fields. For target field display the charset information if it is relevant. For blob type changed the code to use the packlength and display appropriate blob type in error message. For binary and varbinary fields use the slave side character set as reference to map them to binary or varbinary fields.	6 years ago
Alexander Barkov	a8def12e8a	MDEV-20263 sql_mode=ORACLE: BLOB(65535) should not translate to LONGBLOB	6 years ago
Eugene Kosov	d36c107a6b	imporve clang build cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug Maintainer mode makes all warnings errors. This patch fix warnings. Mostly about deprecated `register` keyword. Too much warnings came from Mroonga and I gave up on it.	7 years ago
Eugene Kosov	a82e42fd13	NFC: refactor Field::is_equal() and related stuff Make Field::is_equal() const and return bool as it's a naturally fitting type for it. Also it's agrument was narrowed to Column_definition. InnoDB can change type of some columns by itself. InnoDB-specific code used to reside in Field_xxx:is_equal() methods. Now engine-specific stuff was moved to a virtual methods of handler::can_convert{string,varstring,blob,geom}. These methods are called by Field::can_be_converted_by_engine() which is a double dispatch pattern. Some InnoDB-specific code still resides in compare_keys_but_name(). It should be moved from here someday to handler::compare_key_parts(...) or similar. IS_EQUAL_WITH_REINTERPRET_COMPATIBLE_CHARSET IS_EQUAL_WITH_REINTERPRET_COMPATIBLE_CHARSET_BUT_COLLATE: both was removed IS_EQUAL_NO, IS_EQUAL_YES are not needed now and should be removed along with deprecated handler::check_if_incompatible_data(). HA_EXTENDED_TYPES_CONVERSION: was removed as such logic is not needed now by server code. ALTER_COLUMN_EQUAL_PACK_LENGTH: was renamed to a more generic ALTER_COLUMN_TYPE_CHANGE_BY_ENGINE	7 years ago
Eugene Kosov	854c219a7f	MDEV-17301 Change of COLLATE unnecessarily requires ALGORITHM=COPY Patch is about two cases: 1) On some collate changes it's possible to rebuild only secondary indexes 2) For non-indexed columns collate can be changed INSTANTly Implemented mostly in Field_{string,varstring,blob}::is_equal(). Make this method return how exactly collationa differs. This information is later used by fill_alter_inplace_info() to pass correct info to engine.	7 years ago

1 2 3 4 5 ...

2758 Commits (b915f79e4e004fde4f6ac8f341afee980e11792b)