1. 12 Dec, 2022 3 commits
  2. 08 Dec, 2022 1 commit
    • Monty's avatar
      Fixed bug in Aria when used with enterprise mariadb-backup · dd5f4b36
      Monty authored
      If the backup finished in the middle of a Aria bulk load insert,
      which could happen with LOAD DATA INFILE, CREATE ... SELECT etc)
      there was a chance that Aria recovery would fail on the backup.
      
      Fixed by ensuring that bulk load operations for Aria are not allowed
      under BACKUP LOCK.
      I also changed so that the table TRN is updated just before truncate
      which ensures that old redo's for the table are ignored.
      I also enabled Aria redo for DDL's to be able to repeat REPAIR commands.
      Without this change recovery would not work on repaired tables.
      
      Notes:
      - We take the backup lock protection at the end of bulk insert (as we
        don't want to keep the lock over a very long running insert).
        If mariadb-backup keeps the backup lock too long,  this may fail with
        a lock timeout. In this case the batch insert will fail and the table
        will be truncated (set to it's original state).
      dd5f4b36
  3. 07 Dec, 2022 1 commit
  4. 06 Dec, 2022 1 commit
  5. 05 Dec, 2022 3 commits
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · e55397a4
      Marko Mäkelä authored
      e55397a4
    • Marko Mäkelä's avatar
      MDEV-30148 Race condition between non-persistent statistics and purge · 0a7d85c9
      Marko Mäkelä authored
      btr_cur_t::open_random_leaf(): Replaces btr_cur_open_at_rnd_pos().
      Acquire a shared latch on each page, and finally release all
      latches except the one on the leaf page.
      
      This fixes a race condition between the purge of history and
      btr_estimate_number_of_different_key_vals(), which turned out
      to only hold a buffer-fix on the randomly chosen leaf page.
      Typically, an assertion would fail in page_rec_is_supremum().
      
      ibuf_contract(): Start from the beginning of the change buffer,
      to simplify the logic. Starting with
      commit b42294bc
      it does not matter much where the change buffer merge is being initiated.
      
      The race condition may have been introduced as early as
      mysql/mysql-server@ac74632293bea967b352d1b472abedeeaa921b98
      from where it was copied to
      commit 2e814d47.
      
      Reviewed by: Vladislav Lesin
      Tested by: Matthias Leich
      0a7d85c9
    • Otto Kekäläinen's avatar
      Gitlab-CI: Upgrade Fedora build always use latest (now 37) version · 95d71272
      Otto Kekäläinen authored
      The version was fixed to be Fedora 36 due to previous issues on
      Gitlab-CI, but those seem to be solved now.
      
      Use 'mariadb' name in scripts and server binary as Fedora switched name in
      https://src.fedoraproject.org/rpms/mariadb/c/df76620f9e8a9b3f14da8a615050feeac2c62e26
      
      Switch to using the `default:` section supported by newer Gitlab-CI,
      see https://docs.gitlab.com/ee/ci/yaml/#default.
      
      Also define an explicit timeout of 3 hours to ensure builds don't time
      out if the default timeout is too short.
      
      NOTE TO MERGERS: These changes are version independent and should be
      merged up on all MariaDB branches 10.6 -> 10.11.
      95d71272
  6. 03 Dec, 2022 1 commit
    • Sergei Petrunia's avatar
      MDEV-29129: Performance regression starting in 10.6: select order by limit ... · e0dbec1c
      Sergei Petrunia authored
      The cause of regression was handling for ROWNUM() function.
      For queries like
      
        SELECT ROWNUM() FROM ... ORDER BY ...
      
      ROWNUM() should be computed before the ORDER BY.
      The computation was moved to be before the ORDER BY for any entries in
      the select list that had RAND_TABLE_BIT set.
      
      This had a negative impact on queries in form:
      
        SELECT sp_func() FROM t1 ORDER BY ... LIMIT n
      
      where sp_func() is NOT declared as DETERMINISTIC (and so has
      RAND_TABLE_BIT set).
      
      The fix is to require evaluation for sorting only for the ROWNUM()
      function. Functions that just have RAND_TABLE_BIT() can be computed
      after ORDER BY ... LIMIT is applied.
      
      (think about a possible index that satisfies the ORDER BY clause. In
      that case, the the rows would be read in the needed order and we would
      stop after reading LIMIT rows, achieving the same effect).
      e0dbec1c
  7. 02 Dec, 2022 2 commits
  8. 01 Dec, 2022 1 commit
  9. 30 Nov, 2022 10 commits
  10. 29 Nov, 2022 7 commits
  11. 28 Nov, 2022 8 commits
  12. 26 Nov, 2022 2 commits