1. 21 Jul, 2018 1 commit
  2. 18 Jul, 2018 1 commit
    • Sachin's avatar
      MDEV-16192 Table 't' is specified twice, both as a target for 'CREATE' and... · 9827c5e1
      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.
      9827c5e1
  3. 07 Jul, 2018 1 commit
    • Marko Mäkelä's avatar
      MDEV-16664: Change the default to innodb_lock_schedule_algorithm=fcfs · 1cc1d042
      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.
      1cc1d042
  4. 06 Jul, 2018 2 commits
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-15855 Deadlock between purge thread and DDL statement · 8b0d4cff
      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ä.
      8b0d4cff
    • Marko Mäkelä's avatar
      MDEV-14188 mariabackup.incremental_encrypted wrong result · e3207b6c
      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.
      e3207b6c
  5. 05 Jul, 2018 6 commits
  6. 02 Jul, 2018 1 commit
  7. 01 Jul, 2018 2 commits
    • Anel Husakovic's avatar
      MDEV-16630: Ambiguous error message when check constraint matches table name · 8639e288
      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`.
      8639e288
    • Vladislav Vaintroub's avatar
      amend fix for MDEV-16596 - do not use CREATE_NEW flag when reopening redo log file. · b71c9ae0
      Vladislav Vaintroub authored
      use OPEN_ALWAYS instead, since we know file already exist.
      b71c9ae0
  8. 30 Jun, 2018 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-16596 : Windows - redo log does not work on native 4K sector disks. · c612a1e7
      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.
      c612a1e7
  9. 28 Jun, 2018 11 commits
  10. 27 Jun, 2018 3 commits
  11. 26 Jun, 2018 9 commits
  12. 25 Jun, 2018 2 commits