1. 28 Jul, 2022 2 commits
  2. 27 Jul, 2022 7 commits
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · 30914389
      Marko Mäkelä authored
      30914389
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · 098c0f26
      Marko Mäkelä authored
      098c0f26
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · e5c4f4e5
      Marko Mäkelä authored
      e5c4f4e5
    • Marko Mäkelä's avatar
      MDEV-28495 InnoDB corruption due to lack of file locking · 0ee1082b
      Marko Mäkelä authored
      Starting with commit da094188 (MDEV-24393),
      MariaDB will no longer acquire advisory file locks on InnoDB data
      files by default, because it would create a large number of
      entries in Linux /proc/locks.
      
      The motivation for acquiring the file locks is to prevent accidental
      concurrent startup of multiple server processes on the same data files.
      Such mistake still turns out to be relatively common, based on
      corruption bug reports from the community.
      
      To prevent corruption due to concurrent startup attempts, the
      Aria storage engine would unconditionally acquire an advisory lock
      on one of its log files.
      
      Solution: InnoDB will always lock its system tablespace files.
      (Ever since commit 685d958e
      the InnoDB log file will not necessarily be open while the
      server is running, because it can be accessed via memory-mapped I/O.)
      
      If more protection is desired, then the option --external-locking
      can be used.
      
      The mandatory advisory lock also fixes intermittent failures of
      some crash recovery tests. It turns out that when the mtr test harness
      kills and restarts the server, it will not actually ensure that the
      old process has terminated before starting the new one.
      0ee1082b
    • Oleksandr Byelkin's avatar
      Merge branch '10.3' into 10.4 · 3bb36e94
      Oleksandr Byelkin authored
      3bb36e94
    • Marko Mäkelä's avatar
      MDEV-28950: Add a test case · 772e3f61
      Marko Mäkelä authored
      After reverting commit commit 39f45f6f
      all combinations of this test would crash the server.
      772e3f61
    • Igor Babaev's avatar
      MDEV-29139 Crash when using ANY predicand with redundant subquery in GROUP BY clause · bd935a41
      Igor Babaev authored
      This bug could cause a crash of the server when executing queries containing
      ANY/ALL predicands with redundant subqueries in GROUP BY clauses.
      These subqueries are eliminated by remove_redundant_subquery_clause()
      together with elimination of GROUP BY list containing these subqueries.
      However the references to the elements of the GROUP BY remained in the
      JOIN::all_fields list of the right operand of of the ALL/ANY predicand.
      Later these references confused make_aggr_tables_info() when forming
      proper execution structures after ALL/ANY predicands had been replaced
      with expressions containing MIN/MAX set functions.
      The patch just removes these references from JOIN::all_fields list used
      by the subquery of the ALL/ANY predicand when its GROUP BY clause is
      eliminated.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      bd935a41
  3. 26 Jul, 2022 17 commits
  4. 25 Jul, 2022 7 commits
    • Brandon Nesterenko's avatar
      MDEV-21087/MDEV-21433: ER_SLAVE_INCIDENT arrives at slave without failure specifics · 555c12a5
      Brandon Nesterenko authored
      Problem:
      =======
      
      This patch addresses two issues:
      
       1. An incident event can be incorrectly reported for transactions
      which are rolled back successfully. That is, an incident event
      should only be generated for failed “non-transactional transactions”
      (i.e., those which modify non-transactional tables) because they
      cannot be rolled back.
      
       2. When the mariadb slave (error) stops at receiving the incident
      event there's no description of what led to it. Neither in the event
      nor in the master's error log.
      
      Solution:
      ========
      
      Before reporting an incident event for a transaction, first validate
      that it is “non-transactional” (i.e. cannot be safely rolled back).
      To determine if a transaction is non-transactional,
        lex->stmt_accessed_table(LEX::STMT_WRITES_NON_TRANS_TABLE)
      is used because it is set previously in
      THD::decide_logging_format().
      
      Additionally, when an incident event is written, write an error
      message to the server’s error log to indicate the underlying issue.
      
      Reviewed by:
      ===========
      Andrei Elkin <andrei.elkin@mariadb.com>
      555c12a5
    • Rucha Deodhar's avatar
      This commit is a fixup for MDEV-28762 · 46ff6608
      Rucha Deodhar authored
      46ff6608
    • Marko Mäkelä's avatar
      Fix DBUG_ENTER/return mismatch · f1c8749f
      Marko Mäkelä authored
      Spotted by Thirunarayanan Balathandayuthapani.
      f1c8749f
    • Vlad Lesin's avatar
      MDEV-21136 InnoDB's records_in_range estimates can be way off · 222e800e
      Vlad Lesin authored
      Get rid of BTR_ESTIMATE and btr_cur_t::path_arr.
      
      Before the fix btr_estimate_n_rows_in_range_low() used two
      btr_cur_search_to_nth_level() calls to create two arrays of tree path,
      the array per border. And then it tried to estimate the number of rows
      diving level-by-level with the array elements. As the path pages are
      unlatched during the arrays iterating, the tree could be modified, the
      estimation function called itself until the number of attempts exceed.
      
      After the fix the estimation happens during search process. Roughly, the
      algorithm is the following. Dive in the left page, then if there are pages
      between left and right ones, read a few pages to the right, if the right
      page is reached, fetch it and count the exact number of rows, otherwise
      count the estimated number of rows, and fetch the right page.
      
      The latching order corresponds to WL#6326 rules, i.e.:
      
      (2.1) [same as (1.1)]: Page latches must be acquired in descending order
      of tree level.
      
      (2.2) When acquiring a node pointer page latch at level L, we must hold
      the left sibling page latch (at level L) or some ancestor latch
      (at level>L).
      
      When we dive to the level down, the parent page is unlatched only after
      the the current level page is latched. When we estimate the number of rows
      on some level, we latch the left border, then fetch the next page, and
      then fetch the next page unlatching the previous page after the current
      page is latched until the right border is reached. I.e. the left sibling
      is always latched when we acquire page latch on the same level. When we
      reach the right border, the current page is unlatched, and then the right
      border is latched. Following to (2.2) rule, we can do this because the
      right border's parent is latched.
      222e800e
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-29137 mariabackup excessive logging of ddl tracking · 6156a2be
      Thirunarayanan Balathandayuthapani authored
      - Remove the FILE_MODIFY message from mariabackup which was
      displaying the list of file names which were modified since
      the previous checkpoint.
      6156a2be
    • Marko Mäkelä's avatar
      MDEV-28980 InnoDB: Failing assertion: len <= MAX_TABLE_NAME_LEN · 8aa37c26
      Marko Mäkelä authored
      dict_load_foreigns(): Use a correctly sized buffer for the maximum-length
      SYS_FOREIGN.ID. In case of overflow, do not crash the server but instead
      return DB_CORRUPTION.
      8aa37c26
    • Brad Smith's avatar
  5. 23 Jul, 2022 1 commit
  6. 22 Jul, 2022 3 commits
  7. 21 Jul, 2022 2 commits
  8. 20 Jul, 2022 1 commit