- 21 Jul, 2018 1 commit
-
-
Igor Babaev authored
-
- 18 Jul, 2018 1 commit
-
-
Sachin authored
as a separate source for data Actually MDEV-15867 and MDEV-16192 are same, Slave adds "or replace" to create table stmt. So create table t1 is create or replace on slave. So this bug is not because of replication, We can get this bug on general server if we manually add or replace to create query. Problem:- So if we try to create table t1 (same name as of temp table t1 ) via CREATE or replace TABLE t AS SELECT * FROM t; Since in this query we are creating table from select * from t1 , we call unique_table function to see whether if source and destination table are same. But there is one issue unique_table does not account if source table is tmp table in this case source and destination table can be same. Solution:- We will change find_dup_table to not to look for temp table if CHECK_DUP_SKIP_TEMP_TABLE flag is on.
-
- 07 Jul, 2018 1 commit
-
-
Marko Mäkelä authored
The parameter innodb_lock_schedule_algorithm was introduced in MariaDB Server 10.1.19, 10.2.13, 10.3.4 as part of MDEV-11039. In MariaDB 10.1, the default value of the parameter is 'fcfs', that is, the existing algorithm is used by default. But in later versions of MariaDB Server, the parameter was 'vats', enabling the new algorithm. Because the new algorithm is triggering a debug assertion failure that suggests corruption of the transactional lock data structures, we will revert to the old algorithm by default until we have resolved the problem.
-
- 06 Jul, 2018 2 commits
-
-
Thirunarayanan Balathandayuthapani authored
Problem: ======== Truncate operation holds MDL on the table (t1) and tries to acquire InnoDB dict_operation_lock. Purge holds dict_operation_lock and tries to acquire MDL on the table (t1) to evaluate virtual column expressions for indexed virtual columns. It leads to deadlock of purge and truncate table (DDL). Solution: ========= If purge tries to acquire MDL on the table then it should do the following: i) Purge should release all innodb latches (including dict_operation_lock) before acquiring metadata lock on the table. ii) After acquiring metadata lock on the table, it should check whether the table was dropped or renamed. If the table is dropped then purge should ignore the undo log record. If the table is renamed then it should release the old MDL and acquire MDL on the new name. iii) Once purge acquires MDL, it should use the SQL table handle for all the remaining virtual index for the purge record. purge_node_t: Introduce new virtual column information to know whether the MDL was acquired successfully. This is joint work with Marko Mäkelä.
-
Marko Mäkelä authored
Add an explicit redo log flush. In this test innodb_flush_log_at_trx_commit was 2 by default. It is also possible that this failure occurs because of MDEV-15740.
-
- 05 Jul, 2018 6 commits
-
-
Igor Babaev authored
1. The changed variant did not fail without the patch for MDEV-16629 while the original test case did fail. 2. In any case the test case should go to cte_recursive_not_embedded.test that was not created yet.
-
Marko Mäkelä authored
At the end of a test, 'connection default' should be in a usable state. This was not the case, because there was a preceding 'send' without a 'reap'. If 'reap' was added, an error would be reported because the server was restarted after the 'send'. It is easiest to 'send' from a separate connection and do the restart from 'connection default'.
-
Thirunarayanan Balathandayuthapani authored
Make dict_table_t::n_ref_count private, and protect it with a combination of dict_sys->mutex and atomics. We want to be able to invoke dict_table_t::release() without holding dict_sys->mutex.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Igor Babaev authored
When processing a query containing with clauses a call of the function check_dependencies_in_with_clauses() before opening tables used in the query is necessary if with clauses include specifications of recursive CTEs. This call was missing if such a query belonged to a stored function. This caused misbehavior of the server: it could report a fake error as in the test case for MDEV-16629 or the executed query could hang as in the test cases for MDEV-16661 and MDEV-15151.
-
- 02 Jul, 2018 1 commit
-
-
Vladislav Vaintroub authored
Marko mentions, it could be caused by MDEV-15740 where InnoDB does not flush redo log as often as it should, with innodb_flush_log_at_trx_commit=1 The workaround is to use innodb_flush_log_at_trx_commit=2, which, according to MDEV-15740 is more durable.
-
- 01 Jul, 2018 2 commits
-
-
Anel Husakovic authored
One can create table with the same name for `field` and `table` `check` constraint. For example: `create table t(a int check(a>0), constraint a check(a>10));` But when inserting new rows same error is always raised. For example with ```insert into t values (-1);``` and ```insert into t values (10);``` same error `ER_CONSTRAINT_FAILED` is obtained and it is not clear which constraint is violated. This patch solve this error so that in case if field constraint is violated the first parameter in the error message is `table.field_name` and if table constraint is violated the first parameter in error message is `constraint_name`.
-
Vladislav Vaintroub authored
use OPEN_ALWAYS instead, since we know file already exist.
-
- 30 Jun, 2018 1 commit
-
-
Vladislav Vaintroub authored
Disks with native 4K sectors need 4K alignment and size for unbuffered IO (i.e for files opened with FILE_FLAG_NO_BUFFERING) Innodb opens redo log with FILE_FLAG_NO_BUFFERING, however it always does 512byte IOs. Thus, the IO on 4K native sectors will fail, rendering Innodb non-functional. The fix is to check whether OS_FILE_LOG_BLOCK_SIZE is multiple of logical sector size, and if it is not, reopen the redo log without FILE_FLAG_NO_BUFFERING flag.
-
- 28 Jun, 2018 11 commits
-
-
Sergei Golubchik authored
-
Vladislav Vaintroub authored
Use GetLastError() instead.
-
Sergei Golubchik authored
table->in_use is not always set and a KILL signal can arrive anytime.
-
Andrei Elkin authored
MDEV-7257 made a dump thread to read from binlog concurrently with writers as long as the read bytes are below a water-mark (MYSQL_BIN_LOG::binlog_end_pos). However it appeared to be possible a dump thread reader reach out for bytes past the water mark through a feature of IO_CACHE that fills in the internal buffer and while doing so it could read what the reader is not supposed to see (the bytes above MYSQL_BIN_LOG::binlog_end_pos). The issue is fixed with constraining the IO_CACHE buffer fill to respect the watermark. An added unit test proves reading from file is bound to an external parameter passed to {IO_CACHE::end_of_file} cache member.
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
rnd_pos_by_record calls ha_rnd_pos, which does the counting
-
Sergei Golubchik authored
-
Andrei Elkin authored
MDEV-7257 made a dump thread to read from binlog concurrently with writers as long as the read bytes are below a water-mark (MYSQL_BIN_LOG::binlog_end_pos). However it appeared to be possible a dump thread reader reach out for bytes past the water mark through a feature of IO_CACHE that fills in the internal buffer and while doing so it could read what the reader is not supposed to see (the bytes above MYSQL_BIN_LOG::binlog_end_pos). The issue is fixed with constraining the IO_CACHE buffer fill to respect the watermark. An added unit test proves reading from file is bound to an external parameter passed to {IO_CACHE::end_of_file} cache member.
-
Sergei Golubchik authored
Different fix, just use NULL, not no_db,
-
Igor Babaev authored
The previous correction of the patch for mdev-16473 did not work correctly for the databases whose names started with '*'. Added a test case with a database named "*".
-
- 27 Jun, 2018 3 commits
-
-
Marko Mäkelä authored
-
Sergey Vojtovich authored
Only close stdin if it was open initinally. Otherwise we may close file descriptor which is reused for different puprose (specifically for binlog index file in case of this bug).
-
Jan Lindström authored
This is a typical systemd response where it tries to shutdown the joiner (due to "timeout") before the joiner manages to complete SST. wsrep_sst_wait wsrep_SE_init_wait While waiting the operation to finish use mysql_cond_timedwait instead of mysql_cond_wait and if operation is not finished extend systemd timeout (if needed).
-
- 26 Jun, 2018 9 commits
-
-
Igor Babaev authored
-
Marko Mäkelä authored
-
Daniel Bartholomew authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
dict0dict.cc buf_LRU_drop_page_hash_for_tablespace(): Return whether any adaptive hash index entries existed. If yes, the caller should keep retrying to drop the adaptive hash index. row_import_for_mysql(), row_truncate_table_for_mysql(), row_drop_table_for_mysql(): Ensure that the adaptive hash index was entirely dropped for the table.
-
Eugene Kosov authored
MDEV-15953 Alter InnoDB Partitioned Table Moves Files (which were originally not in the datadir) to the datadir ha_innobase::prepare_inplace_alter_table: preserve DATA DICTIONARY for table
-
Igor Babaev authored
Before this patch if no default database was set the server threw an error for any table name reference that was not fully qualified by database name. In particular it happened for table names referenced CTE tables. This was incorrect. The error message was thrown at the parser stage when the names referencing different tables were not resolved yet. Now if no default database is set and a with clause is used in the processed statement any table reference is just supplied with a dummy database name "*none*" at the parser stage. Later after a call of check_dependencies_in_with_clauses() when the names for CTE tables can be resolved error messages are thrown only for those names that refer to non-CTE tables. This is done in open_and_process_table().
-
- 25 Jun, 2018 2 commits
-
-
Oleksandr Byelkin authored
-
Oleksandr Byelkin authored
register changes of last_gtid
-