1. 10 Aug, 2022 9 commits
  2. 09 Aug, 2022 3 commits
  3. 08 Aug, 2022 4 commits
  4. 05 Aug, 2022 2 commits
    • Marko Mäkelä's avatar
      MDEV-13542 fixup: Improve a recovery error message · c9803504
      Marko Mäkelä authored
      A message used to say "failed to read or decrypt"
      but the "or decrypt" part was removed in
      commit 0b47c126
      without adjusting rarely needed error message suppressions in some
      encryption tests.
      
      Let us improve the error message so that it mentions the file name,
      and adjust all error message suppressions in tests.
      
      Thanks to Oleksandr Byelkin for noticing one test failure.
      c9803504
    • Oleksandr Byelkin's avatar
      fix tests · 5dc86050
      Oleksandr Byelkin authored
      5dc86050
  5. 04 Aug, 2022 10 commits
  6. 03 Aug, 2022 10 commits
  7. 02 Aug, 2022 2 commits
    • Igor Babaev's avatar
      MDEV-28617 Crash with INSERT...SELECT using derived table in GROUP BY clause · c2300d06
      Igor Babaev authored
      This bug manifested itself for INSERT...SELECT and DELETE statements whose
      WHERE condition used an IN/ANY/ALL predicand or a EXISTS predicate with
      such grouping subquery that:
       - its GROUP BY clause could be eliminated,
       - the GROUP clause contained a subquery over a mergeable derived table
         referencing the updated table.
      
      The bug ultimately caused a server crash when the prepare phase of the
      statement processing was executed. This happened after removal redundant
      subqueries used in the eliminated GROUP BY clause from the statement tree.
      The function that excluded the subqueries from the did not do it properly.
      As a result the specification of any derived table contained in a removed
      subquery was not marked as excluded.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      c2300d06
    • Sergei Golubchik's avatar
      MDEV-23097 heap-use-after-free in mysqlimport · 07a670b8
      Sergei Golubchik authored
      mysqlimport starts many worker threads. when one of the worker
      encounters an error, it frees global memory and calls exit().
      
      it suppresses memory leak detector, because, as the comment says
      "dirty exit, some threads are still running", indeed, it cannot
      free the memory from other threads.
      
      but precisely because some threads are still running, they
      might use this global memory, so it cannot be freed.
      
      fix: if we know that some threads are still running and accept
      that we cannot free all memory anyway, let's not free global
      allocations either
      07a670b8