- 31 Aug, 2018 2 commits
-
-
Monty authored
- Made output to be aligned in aria_chk -d - Aria engine error texts are now written instead of "Undefined error" - When running with --check --force, tables with wrong TRN's but otherwise correct are now zerofilled - Fixed several bugs in check and recovery related to fulltext - When doing recovery, store highest found TRID in aria_control_file Before this, the
-
Monty authored
-
- 30 Aug, 2018 4 commits
-
-
Igor Babaev authored
Field_iterator_table_ref::set_field_iterator Several functions that processed different prepare statements missed the DT_INIT flag in last parameter of the open_normal_and_derived_tables() calls. It made context analysis of derived tables dependent on the order in which the derived tables were processed by mysql_handle_derived(). This order was induced by the order of SELECTs in all_select_list. In 10.4 the order of SELECTs in all_select_list became different and lack of the DT_INIT flags in some open_normal_and_derived_tables() call became critical as some derived tables were not identified as such.
-
Monty authored
This also fixes MDEV-16313 Assertion `next_free_value % real_increment == offset' fails upon CREATE SEQUENCE in galera cluster Fixed by adding llabs() to assert. Also adjusted auto_increment_offset to mod auto_increment_increment.
-
Jacob Mathew authored
The SELECT with the INNER JOIN is executed with one of the two tables being optimized as a constant table, which is pre-read. Spider nevertheless attempts to push down the join to the data node. The crash occurs because the constant table is excluded from the optimized query that Spider attempts to push down. In order for Spider to be able to push down a join, the following conditions need to be met: - All of the tables involved in the join need to be included in the optimized query that Spider pushes down. When any of the tables involved in the join is a constant table, it is excluded from the optimized query that Spider attempts to push down. - All fields involved in the query need to be members of tables included in the optimized query. I fixed the problem by preventing Spider from pushing down queries that include a field that is not a member of a table included in the optimized query. This solution fixes the reported problem and also fixes other potential problems. Author: Jacob Mathew. Reviewer: Kentoku Shiba. Merged: Commit 4885baf6 on branch bb-10.3-MDEV-16889
-
Jacob Mathew authored
The SELECT with the INNER JOIN is executed with one of the two tables being optimized as a constant table, which is pre-read. Spider nevertheless attempts to push down the join to the data node. The crash occurs because the constant table is excluded from the optimized query that Spider attempts to push down. In order for Spider to be able to push down a join, the following conditions need to be met: - All of the tables involved in the join need to be included in the optimized query that Spider pushes down. When any of the tables involved in the join is a constant table, it is excluded from the optimized query that Spider attempts to push down. - All fields involved in the query need to be members of tables included in the optimized query. I fixed the problem by preventing Spider from pushing down queries that include a field that is not a member of a table included in the optimized query. This solution fixes the reported problem and also fixes other potential problems. Author: Jacob Mathew. Reviewer: Kentoku Shiba.
-
- 28 Aug, 2018 2 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
- 27 Aug, 2018 3 commits
-
-
Igor Babaev authored
a table value constructor shows wrong number of rows This is another attempt to fix this bug. The previous patch did not take into account that a transformation for ALL/ANY subqueries could be applied to the materialized table that wrapped the table value constructor used as a specification of the subselect used an ALL/ANY subquery. In this case the result of the derived table used a sink of the class select_subselect rather than of the class select_unit. Thus the previous fix could cause memory overwrites when running EXPLAIN for queries with table value constructors in ALL/ANY subselects.
-
Galina Shalygina authored
The bug appears because of the Item_func_in::build_clone() method. The 'array' field for the Item_func_in item that can be pushed into the materialized view/derived table was built in the wrong way. It becomes lame after the pushdown of the condition into the first SELECT that defines that view/derived table. The server crashes in the pushdown into the next SELECT while trying to use already lame 'array' field. To fix it Item_func_in::build_clone() was changed.
-
Jan Lindström authored
MDEV-17058: Test failure on wsrep.variables MDEV-17060: Test failure on galera.galera_var_slave_threads Fix incorrect calculation of increased applier (slave) threads. Note that increase change takes effect "immediately" but we should use proper wait condition to wait it. Reducing the number of slave threads is not immediate as thread will only exit after a replication event.
-
- 26 Aug, 2018 1 commit
-
-
Ming Lin authored
Currently RocksDB engine doesn't update AUTO_INCREMENT in the UPDATE statement. For example, CREATE TABLE t1 (pk INT AUTO_INCREMENT, a INT, PRIMARY KEY(pk)) ENGINE=RocksDB; INSERT INTO t1 (a) VALUES (1); UPDATE t1 SET pk = 3; ==> AUTO_INCREMENT should be updated to 4. Without this fix, it hits the Assertion `dd_val >= last_val' failed in myrocks::ha_rocksdb::load_auto_incr_value_from_index. (cherry picked from commit f7154242)
-
- 25 Aug, 2018 4 commits
-
-
Vicențiu Ciorbaru authored
-
zhzhzoo authored
-
Anel Husakovic authored
Implement according to standard SQL specification 2008. The check_constraints table is used for fetching metadata about the constraints defined for tables in all databases.
-
Igor Babaev authored
introduced in the patch fo MDEV-16934.
-
- 24 Aug, 2018 8 commits
-
-
Sergei Petrunia authored
MDEV-16703: update AUTO_INCREMENT in the UPDATE statement
-
Marko Mäkelä authored
Merge the 10.2 version, which was created by Vasil Dimov.
-
Sergei Golubchik authored
MDEV-17040 sql/sql_yacc_orac.cc is included but sql/sql_yacc_ora.cc isn't included in source archive fix a packaging typo
-
Nikita Malyavin authored
* remove assertion * do not setup `conds` if it's already cached Fixes #823
-
Igor Babaev authored
-
Marko Mäkelä authored
An INSERT into a temporary table would fail to set the index page as modified. If there were no other write operations (such as UPDATE or DELETE) to the page, and the page was evicted, we would read back the old contents of the page, causing corruption or loss of data. page_cur_insert_rec_write_log(): Call mtr_t::set_modified() for temporary tables. Normally this is part of the mlog_open() call, but the mlog_open() call was only present in debug builds. This regression was caused by commit 48192f96 which was preparation for MDEV-11369 and supposed to affect debug builds only. Thanks to Thirunarayanan Balathandayuthapani for debugging.
-
Igor Babaev authored
-
- 23 Aug, 2018 4 commits
-
-
Igor Babaev authored
-
Sergei Petrunia authored
The testcase needs to set in_predicate_conversion_threshold which is only available in debug builds (this is subject to further discussion).
-
Marko Mäkelä authored
-
Marko Mäkelä authored
When a table is renamed to an internal #sql2 or #sql-ib name during a table-rebuilding DDL operation such as OPTIMIZE TABLE or ALTER TABLE, and shortly after that a purge operation in an index on virtual columns is attempted, the operation could fail, but purge would fail to release the table reference. innodb_acquire_mdl(): Release the reference if the table name is not valid for acquiring a meta-data lock (MDL). innodb_find_table_for_vc(): Add a debug assertion if the table name is not valid. This code path is for DML execution. The table should have a valid name for executing DML, and furthermore a MDL will prevent the table from being renamed. row_vers_build_clust_v_col(): Add a debug assertion that both indexes must belong to the same table.
-
- 22 Aug, 2018 2 commits
-
-
Ming Lin authored
Currently RocksDB engine doesn't update AUTO_INCREMENT in the UPDATE statement. For example, CREATE TABLE t1 (pk INT AUTO_INCREMENT, a INT, PRIMARY KEY(pk)) ENGINE=RocksDB; INSERT INTO t1 (a) VALUES (1); UPDATE t1 SET pk = 3; ==> AUTO_INCREMENT should be updated to 4. Without this fix, it hits the Assertion `dd_val >= last_val' failed in myrocks::ha_rocksdb::load_auto_incr_value_from_index.
-
Sergei Golubchik authored
MDEV-16961 Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed upon concurrent DELETE and DDL with virtual blob column After iterating all fields and setting PART_INDIRECT_KEY_FLAG as necessary, TABLE::mark_columns_used_by_virtual_fields() remembers in TABLE_SHARE that this operation was done and need not be repeated. But as the flag is set in TABLE_SHARE, PART_INDIRECT_KEY_FLAG must be set in TABLE_SHARE::field[], not only in TABLE::field[]. Otherwise all new TABLEs opened from this TABLE_SHARE will never have it.
-
- 21 Aug, 2018 10 commits
-
-
Igor Babaev authored
This patch always provides columns of the temporary table used for materialization of a table value constructor with some names. Before this patch these names were always borrowed from the items of the first row of the table value constructor. When this row contained expressions and expressions were not named then it could cause different kinds of problems. In particular if the TVC is used as the specification of a derived table this could cause a crash. The names given to the expressions used in a TVC are the same as those given to the columns of the result set from the corresponding SELECT.
-
Igor Babaev authored
value constructor shows wrong number of rows If the specification of a derived table contained a table value constructor then the optimizer incorrectly estimated the number of rows in the derived table. This happened because the optimizer did not take into account the number of rows in the constructor. The wrong estimate could lead to choosing inefficient execution plans.
-
Marko Mäkelä authored
My conflict resolution for the script did not work out after all, and apparently I was testing a wrong version. Revert MDEV-15511 from MariaDB 10.2 for now.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
trx_purge_add_update_undo_to_history(): Relax the too strict assertion by removing the condition on srv_fast_shutdown (innodb_fast_shutdown). Rollback is allowed during any form of shutdown.
-
Marko Mäkelä authored
buf_dump(): Only generate the output when shutdown is in progress. log_write_up_to(): Only generate the output before actually writing to the redo log files. srv_purge_should_exit(): Rate-limit the output, and instead of displaying the work done, indicate the work that remains to be done until the completion of the slow shutdown.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
Fix the build, which was broken by MDEV-16515.
-
Oleksandr Byelkin authored
-
Daniel Black authored
-