summaryrefslogtreecommitdiff
path: root/sql/field.cc
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-18734 ASAN heap-use-after-free upon sorting by blob column from ↵Aleksey Midenkov2021-08-051-0/+1
| | | | | | | | | | | | | | | | | | | 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
* MDEV-17890 Server crash on DELETE with YEAR field with truncated exprNikita Malyavin2021-07-121-1/+9
| | | | | | | | | | | | | | | | | 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.
* MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failedNikita Malyavin2021-01-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* MDEV-4677 GROUP_CONCAT not showing any output with group_concat_max_len >= 4GbSergei Golubchik2020-12-101-1/+1
| | | | | don't allow group_concat_max_len values >= 4Gb (they never worked anyway)
* MDEV-22387: Do not violate __attribute__((nonnull))Marko Mäkelä2020-11-021-2/+6
| | | | | | | | | | | This follows up commit commit 94a520ddbe39ae97de1135d98699cf2674e6b77e and commit 7c5519c12d46ead947d341cbdcbb6fbbe4d4fe1b. 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.
* Merge branch '10.1' into 10.2Oleksandr Byelkin2020-08-021-27/+72
|\
| * Bug #25207522: INCORRECT ORDER-BY BEHAVIOR ON A PARTITIONED TABLE WITH A ↵Sergei Golubchik2020-07-291-11/+55
| | | | | | | | | | | | | | | | | | 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.
| * MDEV-23282 FLOAT(53,0) badly handles out-of-range valuesAlexander Barkov2020-07-271-4/+5
| | | | | | | | | | truncate_double() did not take into account the max_value limit in case when dec<NOT_FIXED_DEC.
| * Code comment spellfixesIan Gilfillan2020-07-221-13/+13
| |
* | MDEV-18042 Server crashes upon adding a non-null date column under ↵Nikita Malyavin2020-07-311-1/+1
| | | | | | | | | | | | NO_ZERO_DATE with ALGORITHM=INPLACE accept table_name and db_name instead of table_share in make_truncated_value_warning
* | Fix typo in the comment (and old info)Oleksandr Byelkin2020-07-091-1/+1
| |
* | Merge 10.1 into 10.2Marko Mäkelä2020-06-061-3/+2
|\ \ | |/
| * MDEV-22715: SIGSEGV in radixsort_for_str_ptr and in native_compare/my_qsort2 ↵Varun Gupta2020-06-051-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | (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.
| * imporve clang buildEugene Kosov2019-06-251-1/+1
| | | | | | | | | | | | | | | | | | 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.
* | Amend af784385b4a2b286000fa2c658e34283fe7bba60: Avoid vtable overheadMarko Mäkelä2020-05-151-2/+5
| | | | | | | | | | | | 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.
* | Fix for using uninitialized memoryMonty2020-05-151-0/+6
| | | | | | | | | | | | | | | | | | 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.
* | Fixed bugs found by valgrindMonty2020-05-151-1/+1
| | | | | | | | | | | | Other things: - Removed innodb_encryption_tables.test from valgrind as it takes a REALLY long time
* | Fixed memory leak with DEFAULT(f) on Geometry fieldMonty2020-04-181-1/+1
| | | | | | | | | | | | MDEV-21056 Assertion `global_status_var.global_memory_used == 0' failed upon shutdown after query with DEFAULT on a geometry field
* | MDEV-21959 GIS error message doesn't show the wrong value, just the type.Alexey Botchkov2020-03-171-2/+10
| | | | | | | | Error message now shows the whole value.
* | MDEV-21082: isnan/isinf compilation errors, isfinite warnings on MacOSVlad Lesin2019-11-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix consists of three commits backported from 10.3: 1) Cleanup isnan() portability checks (cherry picked from commit 7ffd7fe9627d1f750a3712aebb4503e5ae8aea8e) 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 bc469a0bdf85400f7a63834f5b7af1a513dcdec9) 3) Use std::isfinite in C++ code This is addition to parent revision fixing build failures. (cherry picked from commit 54999f4e75f42baca484ae436b382ca8817df1dd)
* | Backporting 273d8eb12c40a6dcd05a8148bdfba3f1fd96e764 Proper fix for ↵Varun Gupta2019-09-231-17/+20
| | | | | | | | disabling warnings in read_statistics_for_table()
* | MDEV-20589: Server still crashes in Field::set_warning_truncated_wrong_valueVarun Gupta2019-09-181-12/+2
| | | | | | | | | | | | | | 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.
* | MDEV-20403 Assertion `0' or Assertion `btr_validate_index(index, 0)' failed ↵Sergei Golubchik2019-09-041-27/+0
| | | | | | | | | | | | | | | | | | | | | | | | 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 c7c481f4d91
* | Part2: MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, ↵Alexander Barkov2019-09-031-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in ↵Alexander Barkov2019-09-031-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | MDEV-19925: Column ... cannot be converted from type 'varchar(20)' to type ↵Sujatha2019-08-271-0/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'varchar(20)' Cherry picking: Bug#25135304: RBR: WRONG FIELD LENGTH IN ERROR MESSAGE commit 47bd3f7cf3c8518f62b1580ec65af2ba7ac13b95 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.
* | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-1/+1
|\ \ | |/
| * Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| |\
| | * Update FSF AddressVicențiu Ciorbaru2019-05-111-1/+1
| | | | | | | | | | | | * Update wrong zip-code
* | | Merge branch '10.1' into 10.2Oleksandr Byelkin2019-05-041-1/+1
|\ \ \ | |/ /
* | | MDEV-18899: Server crashes in Field::set_warning_truncated_wrong_valueVarun Gupta2019-03-281-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | To fix the crash there we need to make sure that the server while storing the statistical values in statistical tables should do it in a multi-byte safe way. Also there is no need to throw warnings if there is truncation while storing values from statistical fields.
* | | Backporting MDEV-15597 Add class Load_data_outvar and avoid using ↵Alexander Barkov2019-02-231-0/+18
| | | | | | | | | | | | | | | | | | Item::STRING_ITEM for Item_user_var_as_out_param detection This is a part of "MDEV-18045 Backporting the MDEV-15497 changes to 10.2 branch"
* | | Backporting MDEV-15497 Wrong empty value in a GEOMETRY column on LOAD DATAAlexander Barkov2019-02-231-0/+57
| | | | | | | | | | | | This is a part of "MDEV-18045 Backporting the MDEV-15497 changes to 10.2 branch"
* | | Backporting MDEV-14628 Wrong autoinc value assigned by LOAD XML in the ↵Alexander Barkov2019-02-231-0/+51
| | | | | | | | | | | | | | | | | | NO_AUTO_VALUE_ON_ZERO mode This is a part of "MDEV-18045 Backporting the MDEV-15497 changes to 10.2 branch"
* | | MDEV-18083 ASAN heap-use-after-free in ↵Sergei Golubchik2019-02-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Field::set_warning_truncated_wrong_value upon inserting into temporary table remove TABLE_SHARE::error_table_name() and TABLE_SHARE::orig_table_name (that was allocated in a wrong memroot in this bug). instead, simply set TABLE_SHARE::table_name correctly.
* | | MDEV-14576 Include full name of object in message about incorrect value for ↵Alexey Botchkov2018-12-161-7/+26
| | | | | | | | | | | | | | | | | | | | | | | | column. The error message modified. Then the TABLE_SHARE::error_table_name() implementation taken from 10.3, to be used as a name of the table in this message.
* | | MDEV-16217: Assertion `!table || (!table->read_set || ↵bb-10.2-MDEV-16217Oleksandr Byelkin2018-11-141-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed in Field_num::get_date - clean up DEFAULT() to work only with default value and correctly print itself. - fix of DBUG_ASSERT about fields read/write - fix of field marking for write based really on the thd->mark_used_columns flag
* | | Merge branch '10.1' into 10.2Sergei Golubchik2018-09-241-1/+1
|\ \ \ | |/ /
| * | Merge branch '10.0' into 10.1Sergei Golubchik2018-09-231-1/+2
| |\ \
| | * \ Merge remote-tracking branch 'origin/5.5' into 10.0Alexander Barkov2018-09-211-1/+2
| | |\ \ | | | |/
| | | * MDEV-17249 MAKETIME(-1e50,0,0) returns a wrong resultAlexander Barkov2018-09-201-1/+2
| | | |
* | | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-6/+11
|\ \ \ \ | |/ / /
| * | | Merge branch '11.0' into 10.1Oleksandr Byelkin2018-09-061-6/+11
| |\ \ \ | | |/ /
| | * | MDEV-17067 Server crash in write_block_recordMonty2018-08-241-6/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that Create_field::create_length_to_internal_length() calculated a different pack_length for NEWDECIMAL compared to Field_new_decimal constructor which lead to some unused bytes in the middle of the record, which Aria didn't like.
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-021-1/+7
|\ \ \ \ | |/ / /
| * | | MDEV-16711 Crash in Field_blob::store() while reading statisticsIgor Babaev2018-07-151-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for the small InnoDB table This bug was introduced by the patch 6c414fcf89510215d6d3466eb9992d444eadae89. The patch has not taken into account that some objects of the Field_* types are created only for TABLE_SHARE and the field 'table' is set to NULL for them. In particular such are objects created to store statistical min/max values for columns.
* | | | MDEV-12574 MAX(old_decimal) produces a column of the old DECIMAL typeAlexander Barkov2018-06-251-9/+18
| | | |
* | | | MDEV-12809 Bad column type created for TEXT(1431655798) CHARACTER SET utf8Alexander Barkov2018-06-211-1/+1
| | | |
* | | | MDEV-15352 AUTO_INCREMENT breaks after updating a column value to a negative ↵Alexander Barkov2018-06-141-0/+10
| | | | | | | | | | | | | | | | number
* | | | register keyword c++17 warningEugene Kosov2018-04-241-1/+1
| | | |
View Lorry Controller Status