1. 07 Dec, 2018 1 commit
    • Kristian Nielsen's avatar
      Move deletion of old GTID rows to slave background thread · 34f11b06
      Kristian Nielsen authored
      This patch changes how old rows in mysql.gtid_slave_pos* tables are deleted.
      Instead of doing it as part of every replicated transaction in
      record_gtid(), it is done periodically (every @@gtid_cleanup_batch_size
      transaction) in the slave background thread.
      
      This removes the deletion step from the replication process in SQL or worker
      threads, which could speed up replication with many small transactions. It
      also decreases contention on the global mutex LOCK_slave_state. And it
      simplifies the logic, eg. when a replicated transaction fails after having
      deleted old rows.
      
      With this patch, the deletion of old GTID rows happens asynchroneously and
      slightly non-deterministic. Thus the number of old rows in
      mysql.gtid_slave_pos can temporarily exceed @@gtid_cleanup_batch_size. But
      all old rows will be deleted eventually after sufficiently many new GTIDs
      have been replicated.
      34f11b06
  2. 06 Dec, 2018 3 commits
  3. 05 Dec, 2018 3 commits
  4. 04 Dec, 2018 5 commits
  5. 03 Dec, 2018 3 commits
  6. 02 Dec, 2018 2 commits
  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 8 commits
    • Marko Mäkelä's avatar
      More InnoDB preprocessor cleanup · 17e371ff
      Marko Mäkelä authored
      Remove unnecessary #include.
      
      Remove references to UNIV_MATERIALIZE, UNIV_INLINE_ORIGINAL, UNIV_NONINL
      that are never defined.
      17e371ff
    • Marko Mäkelä's avatar
      Re-disable a failing test · 3e5162d8
      Marko Mäkelä authored
      3e5162d8
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 757530b8
      Marko Mäkelä authored
      757530b8
    • 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
      Merge 10.3 into 10.4 · 3afae13b
      Marko Mäkelä authored
      3afae13b
    • 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.3 into 10.4 · b3742467
      Marko Mäkelä authored
      b3742467
    • 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 7 commits
  11. 27 Nov, 2018 2 commits