- 02 Aug, 2021 1 commit
-
-
Oleksandr Byelkin authored
This reverts commit 9b8e207c.
-
- 31 Jul, 2021 1 commit
-
-
Sergei Golubchik authored
fix main.processlist_notembedded test * before EXPLAINing `select sleep` wait for select to start (fixes "Target is not running an EXPLAINable command") * after killing sleep, wait for it to die (fixes test failures on --repeat when old sleep shows on a test rerun) * unify with 10.3, copy minor changes from there (`--echo End of 5.5` vs `--echo # End of 5.5`, etc)
-
- 29 Jul, 2021 2 commits
-
-
Nikita Malyavin authored
len was containing garbage, since vctempl->mysql_col_offset was containing old value while calling row_mysql_store_col_in_innobase_format from innobase_get_computed_value(). It was not updated after the first ALTER TABLE call, because it's INPLACE logic considered there's nothing to update, and exited immediately from ha_innobase::inplace_alter_table(). However, vcol metadata needs an update, since vcols structure is changed in mysql record. The regression was introduced by 12614af1. There, refcount==1 condition was removed, which turned out to be crucial, though racy. The idea was to update vc_templ after each (sequencing) ALTER TABLE. We should do the same another way, and there may be a plenty of solutions, but the simplest one is to add a following condition: if vcol structure is changed, drop vc_templ; it will be recreated on next ha_innobase::open() call. in prepare_inplace_alter_table. It is safe, since innodb inplace changes require at least HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE, which guarantee MDL_EXCLUSIVE on this stage. alter_templ_needs_rebuild() also has to track the columns not indexed, to keep vc_templ correct. Note that vc_templ is always kept constructed and available after ha_innobase::open() call, even on INSERT, though no virtual columns are evaluated during that statement inside innodb. In the test case suplied, it will be recreated on the second ALTER TABLE.
-
Marko Mäkelä authored
ha_innobase::prepare_inplace_alter_table(): Remove always-true conditions. Near the start of the function, we would already have returned if no ALTER TABLE operation flags were set that would require special action from InnoDB. It turns out that the conditions were redundant already when they were introduced in mysql/mysql-server@241387a2b6b61fb8a4f78dc4ad0aaa289400c694 and in commit 068c6197. Thanks to Nikita Malyavin for noticing this.
-
- 28 Jul, 2021 2 commits
-
-
Nikita Malyavin authored
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.
-
Marko Mäkelä authored
Thanks to Nikita Malyavin for noticing this. The dead code that was originally introduced in mysql/mysql-server@b8bd31740cd7088f3a3c164981c7ccda487d301d was added in commit 2e814d47 to this code base.
-
- 27 Jul, 2021 9 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
rename files `version` -> `version_full`
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Marko Mäkelä authored
btr_scrub_start_space(): Avoid an unnecessary tablespace lookup and related acquisition of fil_system->mutex. In MariaDB Server 10.3 we would get deadlocks between that mutex and a crypt_data mutex. The fix was developed by Thirunarayanan Balathandayuthapani.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
On POSIX systems, InnoDB would unconditionally acquire advisory locks on the files that it opens. On Linux, this would be observable by a large number of entries in /proc/locks. Other storage engines would only acquire advisory locks on files based on the Boolean configuration parameter external_locking. Let InnoDB do the same. NOTE: The --skip-external-locking is activated by default. To have InnoDB acquire advisory locks, --external-locking must be specified. Reviewed by: Sergei Golubchik
-
Marko Mäkelä authored
trx_t::will_lock: Changed the type to bool. trx_t::is_autocommit_non_locking(): Replaces trx_is_autocommit_non_locking(). trx_is_ac_nl_ro(): Remove (replaced with equivalent assertion expressions). assert_trx_nonlocking_or_in_list(): Remove. Replaced with at least as strict checks in each place. check_trx_state(): Moved to a static function; partially replaced with individual debug assertions implementing equivalent or stricter checks. This is a backport of commit 7b51d11c from 10.5.
-
- 26 Jul, 2021 4 commits
-
-
Jan Lindström authored
MDEV-26062 : InnoDB: WSREP: referenced FK check fail: Lock wait index `PRIMARY` table `schema`.`child_table` Problem was that not all normal error codes where not handled after wsrep_row_upd_check_foreign_constraints() call. Furhermore, debug assertion did not contain all normal error cases. Changed ib:: calls to WSREP_ calls to use wsrep instrumentation.
-
Thirunarayanan Balathandayuthapani authored
Problem: ========= As a part of MDEV-14398 patch, InnoDB added and removed the tablespace from default encrypt list. But InnoDB removes the tablespace from the default encrypt list too early due to i) other encryption thread working on the tablespace ii) When tablespace is being flushed at the end of key rotation InnoDB fails to decrypt/encrypt the tablespace since the tablespace removed too early and it leads to test case failure. Solution: ========= Avoid the removal of tablespace from default_encrypt_list only when 1) Another active encryption thread working on tablespace 2) Eligible for tablespace key rotation 3) Tablespace is in flushing phase Removed the workaround in encryption.innodb_encryption_filekeys test case.
-
Eugene Kosov authored
-
Rucha Deodhar authored
failed for TokuDB engine CREATE TABLE Analysis: Assertion failure happens because the database doesn't exist to create the table but ha_tokudb::create() still returns false. So error is not reported. Fix: Store the error state and report the error.
-
- 24 Jul, 2021 4 commits
-
-
Elena Stepanova authored
Set tests to non-valgrind: oqgraph.social encryption.innodb-page_encryption binlog_encryption.encrypted_master innodb.innodb-page_compression_lz4 main.lock_multi_bug38499 main.lock_multi_bug38691
-
Olivier Bertrand authored
-
Olivier Bertrand authored
-
Olivier Bertrand authored
modified: storage/connect/bsonudf.cpp modified: storage/connect/jsonudf.cpp - Stringify option is now a ; separated list of columns modified: storage/connect/json.cpp modified: storage/connect/json.h modified: storage/connect/mongo.h modified: storage/connect/tabbson.cpp modified: storage/connect/tabcmg.cpp modified: storage/connect/tabcmg.h modified: storage/connect/tabjmg.cpp modified: storage/connect/tabjmg.h modified: storage/connect/tabjson.cpp - PrepareColist not a static function anymore (+ typo) modified: storage/connect/taboccur.cpp - JDVC: Recognize schema (database) from a wrapper server modified: storage/connect/tabjdbc.cpp
-
- 23 Jul, 2021 3 commits
-
-
Marko Mäkelä authored
In commit 83d2e084 (MDEV-24041) we failed to notice that in addition to the bug with DELETE and ON DELETE CASCADE, there is another bug with UPDATE and ON UPDATE CASCADE. row_ins_foreign_fill_virtual(): Use the correct memory heap for everything that will be reachable from the cascade->update that we return to the caller. Note: It is correct to use the shorter-lived cascade->heap for rec_get_offsets(), because that memory will be abandoned when row_ins_foreign_fill_virtual() returns.
-
Julius Goryavsky authored
MDEV-26080 fixup: fixed .result file for galera_roles test (one word must be enclosed in single quotes).
-
Igor Babaev authored
This bug was fixed by the patch for bug MDEV-26025. Only a new test case is added here.
-
- 22 Jul, 2021 7 commits
-
-
Marko Mäkelä authored
-
Sachin Agarwal authored
Problem: Server throws OOM error when we execute twitter load with SELECTs for UPDATE + UPDATES, and SELECT queries on tables with full-text index. FTS cache->total_memory store count of total memory allocated to FTS cache (for all fulltext indexes on a table). For each word in fts cache, we store doc-id & word position in a node->ilist. we increment cache->total_memory with size of doc-id & word position whereas we allocate ilist in chuck of 16, 32 ,64 bytes or 1.2 times of last size. When we wil insert huge amount of data into the FTS aux index tables then collectively these small chucks for each token become huge unaccounted memory allocated for FTS cache. Fix: Incremented cache->total_memory by size of chunk allocated to node->ilist. RB: 25286 Reviewed by : Rahul Agarkar <rahul.agarkar@oracle.com> mysql/mysql-server@7ab5707f1c4482ed050ed9fa739e9ec0e2fc0ffa
-
Jakub Łopuszański authored
This patch changes it so that we do not free old BP `page_hash`, but rather modify it's parameters, during resize. RB: 26084 Reviewed-by: Marcin Babij <marcin.babij@oracle.com> Reviewed-by: Yasufumi Kinoshita <yasufumi.kinoshita@oracle.com> mysql/mysql-server@ea3adc6a1192e1bca4b4894fd7037e29fbcf0bd0
-
Marko Mäkelä authored
ha_innobase::prepare_inplace_alter_table(): Unless the table is being rebuilt, determine the maximum column length based on the current ROW_FORMAT of the table. When TABLE_SHARE (and the .frm file) contains no explicit ROW_FORMAT, InnoDB table creation or rebuild will use innodb_default_row_format. Based on mysql/mysql-server@3287d33acdc4260806a2a407ca15e9d1e04dddcb
-
Marko Mäkelä authored
-
Marko Mäkelä authored
InnoDB tablespace identifiers and page numbers are 32-bit numbers. Let us use a 32-bit type for them in innochecksum. The changes in commit 1918bdf3 broke the build on 32-bit Windows. Thanks to Vicențiu Ciorbaru for an initial version of this fixup.
-
Anel Husakovic authored
-
- 21 Jul, 2021 4 commits
-
-
Igor Babaev authored
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>
-
Hollow Man authored
-
Heinz Wiesinger authored
This gives a short overview over found/missing dependencies as well as enabled/disabled features. Initial author Heinz Wiesinger <heinz@m2mobi.com> Additions by Vicențiu Ciorbaru <vicentiu@mariadb.org> * Report all plugins enabled via MYSQL_ADD_PLUGIN * Simplify code. Eliminate duplication by making use of WITH_xxx variable values to set feature "ON" / "OFF" state. Reviewed by: wlad@mariadb.com (code details) serg@mariadb.com (the idea)
-
Vicențiu Ciorbaru authored
-
- 20 Jul, 2021 3 commits
-
-
Igor Babaev authored
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.
-
Igor Babaev authored
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>
-
Eugene Kosov authored
-