1. 07 Dec, 2018 8 commits
  2. 06 Dec, 2018 5 commits
  3. 05 Dec, 2018 1 commit
  4. 04 Dec, 2018 2 commits
  5. 03 Dec, 2018 1 commit
  6. 02 Dec, 2018 1 commit
  7. 01 Dec, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-17871 Crash when running explain with CTE · 46960365
      Igor Babaev authored
      When the with clause of a query contains a recursive CTE that is not used
      then processing of EXPLAIN for this query does not require optimization
      of the unit specifying this CTE. In this case if 'derived' is the
      TABLE_LIST object created for this CTE then derived->derived_result is NULL
      and any assignment to derived->derived_result->table causes a crash.
      After fixing this problem in the code of st_select_lex_unit::prepare()
      EXPLAIN for such a query worked without crashes. Yet an execution
      plan for the recursive CTE appeared there. The cause of this problem was
      an incorrect condition used in JOIN::save_explain_data_intern() that
      determined whether CTE was to be optimized or not. A similar condition was
      used in select_describe() and this patch has corrected it as well.
      46960365
  8. 30 Nov, 2018 4 commits
    • Marko Mäkelä's avatar
      Re-disable a failing test · 3e5162d8
      Marko Mäkelä authored
      3e5162d8
    • Marko Mäkelä's avatar
      MDEV-17881: Fix a debug assertion · 95f3c142
      Marko Mäkelä authored
      In 10.3, rec_is_metadata() takes a pointer, while in 10.4 it
      takes a reference as a parameter. I ported this patch from
      10.4 to 10.3, and then only ran a release build, not debug build.
      95f3c142
    • Marko Mäkelä's avatar
      MDEV-17881 Assertion failure in cmp_dtuple_rec_with_match_bytes after instant ADD COLUMN · e46a3aa4
      Marko Mäkelä authored
      The special flag REC_INFO_MIN_REC_FLAG used to be only set on the
      first record in the leftmost node pointer page of each level of the tree.
      It was never set on leaf pages.
      
      MDEV-11369 Instant ADD COLUMN in MariaDB Server 10.3 repurposed the flag
      to identify a hidden metadata record, which is stored in the first record
      on the leftmost leaf page.
      
      If the adaptive hash index points to records in the leftmost leaf page
      after instant ALTER TABLE, we would have such a metadata record in the
      table, an assertion could fail when trying to validate the index record.
      In a release build, we might wrongly qualify the hidden metadata record
      and thus return garbage results.
      
      cmp_dtuple_rec_with_match_bytes(): If the REC_INFO_MIN_REC_FLAG is
      set on the record, assert that this is the first record on the
      leftmost page and that the record is a metadata record, and finally
      return 1, because by definition, anything is greater than the
      minimum record.
      e46a3aa4
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 0abd2766
      Marko Mäkelä authored
      Also, related to MDEV-15522, MDEV-17304, MDEV-17835,
      remove the Galera xtrabackup tests, because xtrabackup never worked
      with MariaDB Server 10.3 due to InnoDB redo log format changes.
      0abd2766
  9. 29 Nov, 2018 5 commits
  10. 28 Nov, 2018 3 commits
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 35184902
      Marko Mäkelä authored
      35184902
    • Marko Mäkelä's avatar
      MDEV-17859 Operating system errors in file operations after failed CREATE · b26e603a
      Marko Mäkelä authored
      This is a regression due to MDEV-17816.
      
      When creating a table fails, we must roll back the dictionary
      transaction. Because the rollback may rename tables, and because
      InnoDB lacks proper undo logging for CREATE operations, we must
      drop the incompletely created table before rolling back the
      transaction, which could include a RENAME operation.
      But, we must not blindly drop the table by name; after all,
      the operation could have failed because another table by the
      same name already existed.
      
      create_table_info_t::m_drop_before_rollback: A flag that is set
      if the table needs to be dropped before transaction rollback.
      
      create_table_info_t::create_table(): Remove some duplicated
      error handling.
      
      ha_innobase::create(): On error, only drop the table if it was
      actually created.
      b26e603a
    • Sergei Petrunia's avatar
      MDEV-13155: XA recovery not supported for RocksDB · 0485e519
      Sergei Petrunia authored
      Added a testcase
      0485e519
  11. 27 Nov, 2018 6 commits
  12. 26 Nov, 2018 3 commits
    • Marko Mäkelä's avatar
      MDEV-17816: Follow-up fix · 861038f2
      Marko Mäkelä authored
      When dropping a partially created table due to failure,
      use SQLCOM_TRUNCATE instead of SQLCOM_DROP_DB, so that
      no foreign key constraints will be touched. If any
      constraints were added as part of the creation, they would
      be reverted as part of the transaction rollback.
      
      We need an explicit call to row_drop_table_for_mysql(),
      because InnoDB does not do proper undo logging for CREATE TABLE,
      but would only drop the table at the end of the rollback.
      This would not work if the transaction combines both
      RENAME and CREATE, like TRUNCATE now does.
      861038f2
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 36359157
      Marko Mäkelä authored
      36359157
    • Marko Mäkelä's avatar
      MDEV-17831 TRUNCATE TABLE removes ROW_FORMAT=COMPRESSED · 971e1d86
      Marko Mäkelä authored
      If a table had a KEY_BLOCK_SIZE attribute, but no ROW_FORMAT,
      it would be created as ROW_FORMAT=COMPRESSED in InnoDB.
      However, TRUNCATE TABLE would lose the KEY_BLOCK_SIZE attribute
      and create the table with the innodb_default_row_format (DYNAMIC).
      
      This is a regression that was introduced by MDEV-13564.
      
      update_create_info_from_table(): Copy also KEY_BLOCK_SIZE.
      971e1d86