summaryrefslogtreecommitdiff
path: root/sql
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-021-2/+4
| | | | | Use better error message when KILL fails even in case TOI fails.
* MDEV-23328 Server hang due to Galera lock conflict resolutionJan Lindström2021-11-011-2/+2
| | | | | * Fix error handling NULL-pointer reference * Add mtr-suppression on galera_ssl_upgrade
* MDEV-23328 Server hang due to Galera lock conflict resolutionsjaakola2021-10-294-25/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mutex order violation when wsrep bf thread kills a conflicting trx, the stack is wsrep_thd_LOCK() wsrep_kill_victim() lock_rec_other_has_conflicting() lock_clust_rec_read_check_and_lock() row_search_mvcc() ha_innobase::index_read() ha_innobase::rnd_pos() handler::ha_rnd_pos() handler::rnd_pos_by_record() handler::ha_rnd_pos_by_record() Rows_log_event::find_row() Update_rows_log_event::do_exec_row() Rows_log_event::do_apply_event() Log_event::apply_event() wsrep_apply_events() and mutexes are taken in the order lock_sys->mutex -> victim_trx->mutex -> victim_thread->LOCK_thd_data When a normal KILL statement is executed, the stack is innobase_kill_query() kill_handlerton() plugin_foreach_with_mask() ha_kill_query() THD::awake() kill_one_thread() and mutexes are victim_thread->LOCK_thd_data -> lock_sys->mutex -> victim_trx->mutex This patch is the plan D variant for fixing potetial mutex locking order exercised by BF aborting and KILL command execution. In this approach, KILL command is replicated as TOI operation. This guarantees total isolation for the KILL command execution in the first node: there is no concurrent replication applying and no concurrent DDL executing. Therefore there is no risk of BF aborting to happen in parallel with KILL command execution either. Potential mutex deadlocks between the different mutex access paths with KILL command execution and BF aborting cannot therefore happen. TOI replication is used, in this approach, purely as means to provide isolated KILL command execution in the first node. KILL command should not (and must not) be applied in secondary nodes. In this patch, we make this sure by skipping KILL execution in secondary nodes, in applying phase, where we bail out if applier thread is trying to execute KILL command. This is effective, but skipping the applying of KILL command could happen much earlier as well. This also fixed unprotected calls to wsrep_thd_abort that will use wsrep_abort_transaction. This is fixed by holding THD::LOCK_thd_data while we abort transaction. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* MDEV-25114: Crash: WSREP: invalid state ROLLED_BACK (FATAL)Jan Lindström2021-10-291-0/+2
| | | | | | Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" This reverts commit 29bbcac0ee841faaa68eeb09c86ff825eabbe6b6.
* Fix message severity for "thread pool blocked" messages.Vladislav Vaintroub2021-10-281-2/+2
| | | | Those messages don't indicate errors, they should be normal warnings.
* MDEV-25402 Assertion `!str || str != Ptr' failed in String::copyAlexander Barkov2021-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assert inside String::copy() prevents copying from from "str" if its own String::Ptr also points to the same memory. The idea of the assert is that copy() performs memory reallocation, and this reallocation can free (and thus invalidate) the memory pointed by Ptr, which can lead to further copying from a freed memory. The assert was incomplete: copy() can free the memory pointed by its Ptr only if String::alloced is true! If the String is not alloced, it is still safe to copy even from the location pointed by Ptr. This scenario demonstrates a safe copy(): const char *tmp= "123"; String str1(tmp, 3); String str2(tmp, 3); // This statement is safe: str2.copy(str1->ptr(), str1->length(), str1->charset(), cs_to, &errors); Inside the copy() the parameter "str" is equal to String::Ptr in this example. But it's still ok to reallocate the memory for str2, because str2 was a constant before the copy() call. Thus reallocation does not make the memory pointed by str1->ptr() invalid. Adjusting the assert condition to allow copying for constant strings.
* MDEV-26868: Session tracking flag in OK_PACKETDiego Dupin2021-10-261-11/+8
| | | | Take into account client capabilities.
* MDEV-23391 Crash/assertion CREATE OR REPLACE TABLE AS SELECT under LOCK TABLEVladislav Vaintroub2021-10-261-6/+8
| | | | | | | | | Happens with Innodb engine. Move unlock_locked_table() past drop_open_table(), and rollback current statement, so that we can actually unlock the table. Anything else results in assertions, in drop, or unlock, or in close_table.
* MDEV-22711 Assertion `nr != 0' failed in handler::update_auto_increment.bb-10.2-mdev-22711-hfAlexey Botchkov2021-10-261-6/+12
| | | | | DBUG_ASSERT removed as the AUTO INCREMENT can actually be 0 when the SET insert_id= 0; was done.
* compilation fixes for sys-devel/gcc-11.2.0:11Sergei Golubchik2021-10-251-1/+0
|
* Fix comment10.2-tmpSergei Petrunia2021-10-221-1/+1
|
* MDEV-26262 fixup: Remove a bogus assertionMarko Mäkelä2021-10-211-3/+0
| | | | | | | In commit 1811fd51fbae9e6c1f06ce93faef2bf1279cd3b6 the assertion should have said error_reported instead of !error_reported. But, that revised assertion would still fail in main.defaults where ER_BAD_DATA is reported during CREATE TABLE.
* MDEV-22445 Crash on HANDLER READ NEXT after XA PREPARENikita Malyavin2021-10-201-0/+3
| | | | | | | The assertion is absolutely correct since no data access is possible after XA PREPARE. The check is added in mysql_ha_read.
* MDEV-26262 frm is corrupted after ER_EXPRESSION_REFERS_TO_UNINIT_FIELDNikita Malyavin2021-10-201-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | This is a duplicate of MDEV-18278 89936f11e965, but I will add an additional assertion Description: The frm corruption should not be reported during CREATE TABLE. Normally it doesn't, and the data to fill TABLE is taken by open_table_from_share call. However, the vcol data is stored as SQL string in table->s->vcol_defs.str and is anyway parsed on each table open. It is impossible [or hard] to avoid, because it's hard to clone the expression tree in general (it's easier to parse). Normally parse_vcol_defs should only fail on semantic errors. If so, error_reported is set to true. Any other failure is not expected during table creation. There is either unhandled/unacknowledged error, or something went really wrong, like memory reject. This all should be asserted anyway. Solution: * Set *error_reported=true for the forward references check; * Assert for every unacknowledged error during table creation.
* MDEV-24585 Assertion `je->s.cs == nice_js->charset()' failed in json_nice.bb-10.2-mdev-24585-hfAlexey Botchkov2021-10-191-0/+1
| | | | | We should set the charset in Item_func_json_format::fix_length_and_dec().
* MDEV-26299: Some views force server (and mysqldump) to generate invalid SQL ↵Oleksandr Byelkin2021-10-181-2/+21
| | | | | | | | for their definitions Do not print illegal table field names for non-top-level SELECT list, they will not be refered in any case but create problem for parsing of printed result.
* MDEV-25284: Assertion `info->type == READ_CACHE || info->type == ↵bb-10.2-MDEV-25284Brandon Nesterenko2021-10-184-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | WRITE_CACHE' failed Problem: ======== This patch addresses two issues. First, if a CHANGE MASTER command is issued and an error happens while locating the replica’s relay logs, the logs can be put into an invalid state where future updates fail and future CHANGE MASTER calls crash the server. More specifically, right before a replica purges the relay logs (part of the `CHANGE MASTER TO` logic), the relay log is temporarily closed with state LOG_TO_BE_OPENED. If the server errors in-between the temporary log closure and purge, i.e. during the function find_log_pos, the log should be closed. MDEV-25284 reveals the log is not properly closed. Second, upon issuing a RESET SLAVE ALL command, a slave’s GTID filters are not cleared (DO_DOMAIN_IDS, IGNORE_DOMIAN_IDS, IGNORE_SERVER_IDS). MySQL had a similar bug report, Bug #18816897, which fixed this issue to clear IGNORE_SERVER_IDS after issuing RESET SLAVE ALL in version 5.7. Solution: ========= To fix the first problem, the CHANGE MASTER error handling logic was extended to transition the relay log state to LOG_CLOSED from LOG_TO_BE_OPENED. To fix the second problem, the RESET SLAVE ALL logic is extended to clear the domain_id filter and ignore_server_ids. Reviewed By: ============ Andrei Elkin <andrei.elkin@mariadb.com>
* MDEV-17964: Assertion `status == 0' failed in add_role_user_mapping_actionVicențiu Ciorbaru2021-10-151-189/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This happens upon CREATE USER and DROP ROLE. The underlying problem is that our HASH implementation shuffles elements around when performing an update or delete. This means that when doing a scan through the HASH table by index, in search of elements to delete or update one must restart the scan to make sure nothing is missed if at least one delete / update happened. More specifically, what happened in this case: The hash has 131 element, DROP ROLE removes the element [119]. Its [119]->next was element [129], so [129] is moved to [119]. Now we need to compact the hash, removing the last element [130]. It gets one bit off its hash value and becomes element [2]. The existing element [2] is moved to [129], and old [130] is moved to [2]. We cannot simply move [130] to [129] and make [2]->next=130, it won't work if [2] is itself in the collision list and doesn't belong in [2]. The handle_grant_struct code assumed that it is safe to continue by only reexamining the currently modified / deleted element index, but that is not true. Missing to delete an element in the hash triggered the assertion in the test case. DROP ROLE would not clear all necessary role->role or role->user mappings. To fix the problem we ensure that the scan is restarted, only if an element was deleted / updated, similar to how bubble-sort keeps sorting until it finds no more elements to swap.
* MDEV-23408 Wrong result upon query from I_S and further Assertion ↵Alexander Barkov2021-10-143-3/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | `!alias_arg || strlen(alias_arg->str) == alias_arg->length' failed with certain connection charset There were two independent problems which lead to the crash and to the non-relevant records returned in I_S queries: - The code in the I_S implementation was not secure about values with 0x00 bytes. It's fixed by using check_db_name() and check_table_name() inside make_table_name_list(), and by adding the test for 0x00 inside check_table_name(). - The code in Item_string::print() did not convert strings without introducers when restoring the CREATE VIEW statement from an Item tree. This made wrong literals inside the "query" line in the view FRM file in cases when the VIEW parse time character_set_client!=character_set_connection. That's fixed by adding a proper conversion. This change also fixed a similar problem in SHOW PROCEDURE CODE - the literals were displayed in wrong character set in SP instructions in cases when the SP parse time character_set_client!=character_set_connection.
* MDEV-26712 row events never reset thd->mem_rootAndrei Elkin2021-10-131-6/+11
| | | | | | but must do that at the end of the statement. A provide template patch is elaborated also to match to the upstream fixes of the very same bug.
* MDEV-25925 Warning: Memory not freed: 32 on INSERT DELAYEDbb-10.2-bar-MDEV-25925Alexander Barkov2021-10-111-0/+11
| | | | | | | | | | | | | | | | Also fixes MDEV-24467 Memory not freed after failed INSERT DELAYED Description: In case of an error (e.g. data truncation) during mysql_insert() handling an INSERT DELAYED, the data type specific data in fields (e.g. Field_blob::value) is not taken over by the delayed writer thread. All fields in table_list->table are freed by free_root() immediately after mysql_insert(). To avoid a memory leak, we need to free the specific data before exiting mysql_insert() on error.
* MDEV-23269 SIGSEGV in ft_boolean_check_syntax_string on setting ↵bb-10.2-bar-MDEV-23269Alexander Barkov2021-10-112-2/+6
| | | | | | | | | | | | | | ft_boolean_syntax The crash happened because my_isalnum() does not support character sets with mbminlen>1. The value of "ft_boolean_syntax" is converted to utf8 in do_string_check(). So calling my_isalnum() is combination with "default_charset_info" was wrong. Adding new parameters (size_t length, CHARSET_INFO *cs) to ft_boolean_check_syntax_string() and passing self->charset(thd) as the character set.
* MDEV-24742 Server crashes in Charset::numchars / String::numcharsbb-10.2-bar-MDEV-24742Alexander Barkov2021-10-111-0/+2
| | | | | The crash happened because Item_aes_crypt::val_str() did not set the character set of the result.
* MDEV-18278 Misleading error message in error log upon failed table creationAleksey Midenkov2021-10-111-0/+3
| | | | | If error_reported is not set upper caller open_table_from_share() throws error ER_NOT_FORM_FILE itself via open_table_error().
* MDEV-14846 InnoDB: assertion on trx->state because of deadlock error ignoredAleksey Midenkov2021-10-111-17/+24
| | | | | | | | | | On deadlock transaction is rolled back (and trx->state is cleared) but SELECT continued the loop because evaluate_join_record() ignored the error status returned from lower join evaluation. val_int() does not return error status so it is checked by thd->is_error(). Test case was created by Thirunarayanan Balathandayuthapani <thiru@mariadb.com>
* Make Explain_node::children protectedSergei Petrunia2021-10-081-0/+2
|
* Fix MSVC warning with bison 3.8.2Vladislav Vaintroub2021-10-031-1/+2
|
* MDEV-24454 Crash at change_item_treebb-10.2-MDEV-24454Oleksandr Byelkin2021-09-276-39/+80
| | | | | | | | | | | | | Use in_sum_func (and so nest_level) only in LEX to which SELECT lex belong to Reduce usage of current_select (because it does not always point on the correct SELECT_LEX, for example with prepare. Change context for all classes inherited from Item_ident (was only for Item_field) in case of pushing down it to HAVING. Now name resolution context have to have SELECT_LEX reference if the context is present. Fixed feedback plugin stack usage.
* Revert MDEV-25114Marko Mäkelä2021-09-248-137/+44
| | | | | | Revert 88a4be75a5f3b8d59ac8f6347ff2c197813c05dc and 9d97f92febc89941784d17d59c60275e21140ce0, which had been prematurely pushed by accident.
* MDEV-25114 Crash: WSREP: invalid state ROLLED_BACK (FATAL)sjaakola2021-09-248-46/+137
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is the plan D variant for fixing potetial mutex locking order exercised by BF aborting and KILL command execution. In this approach, KILL command is replicated as TOI operation. This guarantees total isolation for the KILL command execution in the first node: there is no concurrent replication applying and no concurrent DDL executing. Therefore there is no risk of BF aborting to happen in parallel with KILL command execution either. Potential mutex deadlocks between the different mutex access paths with KILL command execution and BF aborting cannot therefore happen. TOI replication is used, in this approach, purely as means to provide isolated KILL command execution in the first node. KILL command should not (and must not) be applied in secondary nodes. In this patch, we make this sure by skipping KILL execution in secondary nodes, in applying phase, where we bail out if applier thread is trying to execute KILL command. This is effective, but skipping the applying of KILL command could happen much earlier as well. This patch also fixes mutex locking order and unprotected THD member accesses on bf aborting case. We try to hold THD::LOCK_thd_data during bf aborting. Only case where it is not possible is at wsrep_abort_transaction before call wsrep_innobase_kill_one_trx where we take InnoDB mutexes first and then THD::LOCK_thd_data. This will also fix possible race condition during close_connection and while wsrep is disconnecting connections. Added wsrep_bf_kill_debug test case Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* Revert "MDEV-23328 Server hang due to Galera lock conflict resolution" andJan Lindström2021-09-241-0/+2
| | | | | | | Revert "MDEV-24873 galera.galera_as_slave_ctas MTR failed:..." This reverts commit 29bbcac0ee841faaa68eeb09c86ff825eabbe6b6 and later commit 5ecaf52d42a1e464c71515f35be97855072bcafe.
* Silence a warning about unused Bison labelMarko Mäkelä2021-09-221-0/+3
|
* Bison 3.7 - fix "conversion from 'ptrdiff_t' to 'ulong', possible loss of data"Vladislav Vaintroub2021-09-112-4/+4
|
* MDEV-23365: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())'bb-10.2-MDEV-23365Rucha Deodhar2021-09-061-1/+3
| | | | | | | | | | | failed upon killed TRUNCATE Note: This is a backport of 1cb4caa66d5fd2a9bc095d68988324b7b358d70f from 10.3 Analysis: Assertion failure happens because less session memory is set and so table can't be reopened. So the statement can't be used. This error goes unreported. Fix: Return the error state.
* MDEV-26529: binlog.binlog_flush_binlogs_delete_domain fails on RISC-Vbb-10.2-danielblack-MDEV-26529-riscv-test-failDaniel Black2021-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Per https://bugs.gentoo.org/807995 The test failed with: CURRENT_TEST: binlog.binlog_flush_binlogs_delete_domain — /tmp/mariadb-10.5.11/mysql-test/suite/binlog/r/binlog_flush_binlogs_delete_domain.result 2021-06-18 18:19:11.000000000 +0800 +++ /tmp/mariadb-10.5.11/mysql-test/suite/binlog/r/binlog_flush_binlogs_delete_domain.reject 2021-09-01 22:55:29.406655479 +0800 @@ -85,6 +85,6 @@ ERROR HY000: The value of gtid domain being deleted ('4294967296') exceeds its maximum size of 32 bit unsigned integer FLUSH BINARY LOGS DELETE_DOMAIN_ID = (4294967295); Warnings: -Warning 1076 The gtid domain being deleted ('4294967295') is not in the current binlog state +Warning 1076 The gtid domain being deleted ('18446744073709551615') is not in the current binlog state DROP TABLE t; RESET MASTER; mysqltest: Result length mismatch ptr_domain_id is a uint32* so explicitly cast this when printing it out. Thanks Marek Szuba for the bug report and testing the patch.
* MDEV-26504 THD::copy_db_to() fails to return true if THD::db is nullMarko Mäkelä2021-08-301-3/+1
| | | | | | | | | | | | | | THD::copy_db_to(): Always return true if the output parameter was left uninitialized. This fixes a regression that was caused by commit 7d0d934ca642e485b2c008727dc20c83e26cce10 (MDEV-16473). MariaDB Server 10.3 and later were unaffected by this bug thanks to commit a7e352b54ddfaf91c92951d605cb02a4ffd2676b. Possibly this bug only affects mysql_list_fields() in the Embedded Server (libmysqld). This bug was found by GCC 11.2.0 in CMAKE_BUILD_TYPE=RelWithDebInfo.
* MDEV-26350: select_lex->ref_pointer_array.size() % 5 == 0Daniel Black2021-08-181-2/+3
| | | | | | | | | | | | Due to an integer overflow an invalid size of ref_pointer_array could be allocated. Using size_t allows this continue. Allocation failures are handled gracefully if the value is too big. Thanks to Zuming Jiang for the bug report and fuzzing MariaDB. Reviewer: Sanja
* MDEV-18734 ASAN heap-use-after-free upon sorting by blob column from ↵Aleksey Midenkov2021-08-055-59/+199
| | | | | | | | | | | | | | | | | | | 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-26220 Server crashes with indexed by prefix virtual columnmariadb-10.2.40Nikita Malyavin2021-08-021-0/+15
| | | | | | | | | | | | | | | Server crashes in Field::register_field_in_read_map upon select from partitioned table with indexed by prefix virtual column. After several read-mark fixes a problem has surfaced: Since KEY (c(10),a) uses only a prefix of c, a new field is created, duplicated from table->field[3], with a new length. However, vcol_inco->expr is not copied. Therefore, (*key_info)->key_part[i].field->vcol_info->expr was left NULL in ha_partition::index_init(). Solution: copy vcol_info from table field when it's set up.
* Revert "MDEV-26220 Server crashes with indexed by prefix virtual column"Oleksandr Byelkin2021-08-021-65/+48
| | | | This reverts commit 9b8e207ce03b2ab7a766348738055be9520561bd.
* MDEV-26220 Server crashes with indexed by prefix virtual columnNikita Malyavin2021-07-281-48/+65
| | | | | | | | | | | | | | | | | Server crashes in Field::register_field_in_read_map upon select from partitioned table with indexed by prefix virtual column. After several read-mark fixes a problem has surfaced: Since KEY (c(10),a) uses only a prefix of c, a new field is created, duplicated from table->field[3], with a new length. However, vcol_inco->expr is not copied. Therefore, (*key_info)->key_part[i].field->vcol_info->expr was left NULL in ha_partition::index_init(). Solution: initialize vcols before key initialization Also key initialization is moved to a function.
* MDEV-26189 Missing handling of unknown column in WHERE of recursive CTEIgor Babaev2021-07-213-5/+12
| | | | | | | | | | | | | | SQL processor failed to catch references to unknown columns and other errors of the phase of semantic analysis in the specification of a hanging recursive CTE. This happened because the function With_clause::prepare_unreferenced_elements() failed to detect a CTE as a hanging CTE if the CTE was recursive. Fixing this problem in the code of the mentioned function opened another problem: EXPLAIN started including the lines for the specifications of hanging recursive CTEs in its output. This problem also was fixed in this patch. Approved by Dmitry Shulga <dmitry.shulga@mariadb.com>
* Typo fixes in item_strfunc.ccHollow Man2021-07-211-7/+7
|
* MDEV-25565 Crash on 2-nd execution of SP/PS for query calculating window ↵Igor Babaev2021-07-203-1/+42
| | | | | | | | | | | | | | | | | | | | | | | functions from view A crash of the server happened when executing a stored procedure whose the only query calculated window functions over a mergeable view specified as a select from non-mergeable view. The crash could be reproduced if the window specifications of the window functions were identical and both contained PARTITION lists and ORDER BY lists. A crash also happened on the second execution of the prepared statement created for such query. If to use derived tables or CTE instead of views the problem still manifests itself crashing the server. When optimizing the window specifications of a window function the server can substitute the partition lists and the order lists for the corresponding lists from another window specification in the case when the lists are identical. This substitution is not permanent and should be rolled back before the second execution. It was not done and this ultimately led to a crash when resolving the column names at the second execution of SP/PS.
* MDEV-26025 Server crashes while executing query with CTE in PS/SPIgor Babaev2021-07-201-5/+10
| | | | | | | | | | | This bug appeared after the patch for bug MDEV-23886. Due to this bug execution of queries with CTEs used the same CTE at least twice via prepared statements or with stored procedures caused crashes of the server. It happened because the select created for any of not the first usage of a CTE erroneously was not included into all_selects_list. This patch corrects the patch applied to fix the bug MDEV-26108. Approved by Oleksandr Byelkin <sanja@mariadb.com>
* MDEV-26135 Assertion failure when executing PS with a hanging recursive CTEIgor Babaev2021-07-191-2/+4
| | | | | | | | | | | | | | The bug affected execution of queries with With clauses containing so-called hanging recursive CTEs in PREPARE mode. A CTE is hanging if it's not used in the query. Preparation of a prepared statement from a query with a hanging CTE caused a leak in the server and execution of this prepared statement led to an assert failure of the server built in the debug mode. This happened because the units specifying recursive CTEs erroneously were not cleaned up if those CTEs were hanging. The patch enforces cleanup of hanging recursive CTEs in the same way as other hanging CTEs. Approved by dmitry.shulga@mariadb.com
* MDEV-26145: Incorrect metadata is sent on running query with union in PS modeDmitry Shulga2021-07-191-1/+6
| | | | | | | | | | | | | | | | | | | Test cases like the following one produce different result sets if it's run with and without th option --ps-protocol. CREATE TABLE t1(a INT); --enable_metadata (SELECT MAX(a) FROM t1) UNION (SELECT MAX(a) FROM t1); --disable_metadata DROP TABLE t1; Result sets differ in metadata for the query (SELECT MAX(a) FROM t1) UNION (SELECT MAX(a) FROM t1); The reason for different content of query metadata is that for queries with union the items being created on JOIN preparing phase is placed into item_list from SELECT_LEX_UNIT whereas for queries without union item_list from SELECT_LEX is used instead.
* MDEV-23597 Assertion `marked_for_read()' failed while evaluating DEFAULTNikita Malyavin2021-07-166-7/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | The columns that are part of DEFAULT expression were not read-marked in statements like UPDATE...SET b=DEFAULT. The problem is `F(DEFAULT)` expression depends of the left-hand side of an assignment. However, setup_fields accepts only right-hand side value. Neither Item::fix_fields does. Suchwise, b=DEFAULT(b) works fine, because Item_default_field has information on what field it is default of: if (thd->mark_used_columns != MARK_COLUMNS_NONE) def_field->default_value->expr->update_used_tables(); in Item_default_value::fix_fields(). It is not reasonable to pass a left-hand side to Item:fix_fields, because the case is rare, so the rewrite b= F(DEFAULT) -> b= F(DEFAULT(b)) is made instead. Both UPDATE and multi-UPDATE are affected, however any form of INSERT is not: it marks all the fields in DEFAULT expressions for read in TABLE::mark_default_fields_for_write().
* MDEV-25858: Query results are incorrect when indexes are addedSergei Petrunia2021-07-151-0/+12
| | | | | | | | If test_if_skip_sort_order() decides to use an index to produce required ordering, it should disable "Range Checked for each record" optimization. This is because Range-Checked-for-each-record may decide to use an index (or an index_merge) which will not produce the required ordering.
* MDEV-18249 ASSERT_COLUMN_MARKED_FOR_READ failed in ANALYZE TABLENikita Malyavin2021-07-121-2/+2
| | | | | | | | | | | The problem is the same as in MDEV-18166: columns in virtual field expression are not marked for read, while the field itself does. field->register_field_in_read_map() should be called for read-marking all fields. The test is reproduced only in 10.4+, however the fix is applicable to 10.2+.
View Lorry Controller Status