1. 24 May, 2024 1 commit
  2. 23 May, 2024 3 commits
    • Marko Mäkelä's avatar
      MDEV-34212 InnoDB transaction recovery is incorrect · 727b5493
      Marko Mäkelä authored
      trx_undo_mem_create_at_db_start(): Invoke recv_sys_t::recover()
      instead of buf_page_get_gen(), so that all undo log pages will be
      recovered correctly. Failure to do this could prevent InnoDB from
      starting up due to "Data structure corruption", or it could
      potentially lead to a situation where InnoDB starts up but some
      transactions were recovered incorrectly.
      
      recv_sys_t::recover(): Only acquire a buffer-fix on the pages,
      not a shared latch. This is adequate protection, because this function
      is only being invoked during early startup when no "users" are modifying
      buffer pool pages. The only writes are due to server bootstrap
      (the data files being created) or crash recovery (changes from
      ib_logfile0 being applied).
      
      buf_page_get_gen(): Assert that the function is not invoked while crash
      recovery is in progress, and that the special mode BUF_GET_RECOVER is
      only invoked during crash recovery or server bootstrap.
      
      All this should really have been part of
      commit 850d6173 (MDEV-32042).
      727b5493
    • Alexander Barkov's avatar
      MDEV-33729 UBSAN negation of -X cannot be represented in type 'long long int';... · 2dfc6c44
      Alexander Barkov authored
      MDEV-33729 UBSAN negation of -X cannot be represented in type 'long long int'; cast to an unsigned type to negate this value to itself in my_strntoll_mb2_or_mb4
      
      The problem was introduced by MDEV-30879.
      The function my_strntoll_8bit() was correctly changed by MDEV-30879.
      The function my_strntoll_mb2_or_mb4() was not.
      
      Applying the missing change to my_strntoll_mb2_or_mb4().
      2dfc6c44
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-34200 InnoDB tries to write to read-only system tablespace · 6c0eb29d
      Thirunarayanan Balathandayuthapani authored
      		in buf_dblwr_t::init_or_load_pages()
      
      - InnoDB fails to set the TRX_SYS_DOUBLEWRITE_SPACE_ID_STORED
      flag in transaction system header page while recreating
      the undo log tablespaces
      
      buf_dblwr_t::init_or_load_pages(): Tries to reset the
      space id and try to write into doublewrite buffer even
      when read_only mode is enabled.
      
      In srv_all_undo_tablespaces_open(), InnoDB should try to
      open the extra unused undo tablespaces instead of trying to
      creating it.
      6c0eb29d
  3. 22 May, 2024 5 commits
    • Marko Mäkelä's avatar
      Merge 11.2 into 11.4 · d2c9d86e
      Marko Mäkelä authored
      d2c9d86e
    • Marko Mäkelä's avatar
      MDEV-34216 Possible corruption when shrinking the system tablespace on innodb_fast_shutdown=0 · b793feb1
      Marko Mäkelä authored
      This bug was found related to MDEV-34212.
      
      Some InnoDB tests, most notably innodb.table_flags,64k would occasionally
      fail. I am able to reproduce this locally on a MemorySanitizer build,
      sporadically.
      
      The following is a minimal .test file for reproducing this:
        --source include/have_innodb.inc
        SELECT @@innodb_page_size;
      and the .opt file:
        --innodb-undo-tablespaces=0 --innodb-page-size=64k
        --innodb-buffer-pool-size=20m
      
      This bug was revealed due to the recent
      commit 466ae1cf
      which set innodb_fast_shutdown=0 during server bootstrap
      in our regression test driver.
      
      Due to the bug, a write of undo page 50 in the system tablespace
      was discarded in buf_page_t::flush(). A subsequent InnoDB startup
      failed because an old version of that page would point to a
      freed undo log page 300.
      
      mtr_t::commit_shrink(): Only invoke fil_space_t::set_create_lsn()
      on undo tablespaces, which will be fully reinitialized or created
      from the scratch. On the system tablespace, we must only adjust
      the file size, to avoid writing pages that are beyond the end
      of the tablespace. Thanks to Thirunarayanan Balathandayuthapani
      for providing this fix.
      b793feb1
    • Oleksandr Byelkin's avatar
      new CC 3.4 · eede2221
      Oleksandr Byelkin authored
      eede2221
    • Marko Mäkelä's avatar
      Merge 11.2 into 11.4 · cb273d53
      Marko Mäkelä authored
      cb273d53
    • Marko Mäkelä's avatar
      MDEV-34209 InnoDB is disregarding read-only mode on slow shutdown · ff377d3b
      Marko Mäkelä authored
      innobase_end(): Do not attempt to shrink the system tablespace if
      innodb_read_only=ON or innodb_force_recovery>4. This fixes a regression
      due to commit 2d6c2f22 (MDEV-32452).
      
      This bug was caught when testing a fix of MDEV-34200, which adds
      SET GLOBAL innodb_fast_shutdown=0 to the test innodb.undo_upgrade.
      ff377d3b
  4. 21 May, 2024 4 commits
  5. 20 May, 2024 3 commits
    • Marko Mäkelä's avatar
      Merge 11.1 into 11.2 · dfe030fd
      Marko Mäkelä authored
      dfe030fd
    • Marko Mäkelä's avatar
      Merge 11.0 into 11.1 · 6fd4fa7d
      Marko Mäkelä authored
      6fd4fa7d
    • Marko Mäkelä's avatar
      MDEV-33588/MDEV-33325 after-merge fix · 2e267a4a
      Marko Mäkelä authored
      In the merge commit f9807aad
      there were some omissions or errors.
      
      ibuf_remove_free_page(): Return an error if the free list is corrupted
      when removing the change buffer on an upgrade. A special 11.0 version of
      commit 263932d5 would have been useful.
      
      buf_page_get_gen(): Correctly handle the case that a page was being
      concurrently read into the buffer pool and found out to be corrupted.
      This was part of commit a4cda66e
      but had been discarded in the merge.
      
      Because MariaDB Server 11.0 has reached its end of life as of
      commit 466ae1cf this fix is being applied
      to the 11.1 branch.
      2e267a4a
  6. 15 May, 2024 3 commits
    • Daniel Bartholomew's avatar
      bump the VERSION · fcee83f0
      Daniel Bartholomew authored
      fcee83f0
    • Daniel Bartholomew's avatar
      bump the VERSION · 339aba04
      Daniel Bartholomew authored
      339aba04
    • Hugo Wen's avatar
      MDEV-34112 Replace one operator name keyword · d1e230d9
      Hugo Wen authored
      Alternative operator name keywords like `and`, `or`, `xor`, etc., are
      uncommon in MariaDB and can cause obscure build errors when the GCC
      flag `-fno-operator-names` is applied.
      
      Description of `-fno-operator-names`:
      https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
      > Do not treat the operator name keywords `and`, `bitand`, `bitor`,
      > `compl`, `not`, `or` and `xor` as synonyms as keywords.
      
      Part of the build errors:
      
          /local/p4clients/pkgbuild-LdLa_/workspace/src/RDSMariaDB/sql/sql_select.cc:11171:28: error: expected ‘)’ before ‘and’
          11171 |     DBUG_ASSERT(sel >= 0.0 and sel <= 1.00001);
                |                            ^~~
          /local/p4clients/pkgbuild-LdLa_/workspace/src/RDSMariaDB/include/my_global.h:372:44: note: in definition of macro ‘unlikely’
            372 | #define unlikely(x)     __builtin_expect(((x) != 0),0)
                |                                            ^
          ...
      
      The build failure is caused by using alternative operator name keywords
      `and` introduced in commit b66cdbd1.
      Replace the `and` keyword with `&&` and target on MariaDB 11.0+ branches
      which include the commit.
      
      All new code of the whole pull request, including one or several files
      that are either new files or modified ones, are contributed under the
      BSD-new license. I am contributing on behalf of my employer
      Amazon Web Services, Inc.
      d1e230d9
  7. 13 May, 2024 5 commits
    • Sergei Golubchik's avatar
      main.alter_table_online fails in --view · db06c5dd
      Sergei Golubchik authored
      disable view protocol (DROP VIEW doesn't work very well with transactions)
      and cosmetic cleanups
      db06c5dd
    • Sergei Golubchik's avatar
      Merge branch '11.1' into 11.2 · bf5da43e
      Sergei Golubchik authored
      bf5da43e
    • Sergei Golubchik's avatar
      remove redundant slow tests · f8621f2a
      Sergei Golubchik authored
      f8621f2a
    • Sergei Petrunia's avatar
      MDEV-33533: Crash at execution of DELETE when trying to use rowid filter · fe41171c
      Sergei Petrunia authored
      (Based on original patch by Oleksandr Byelkin)
      
      Multi-table DELETE can execute via "buffered" mode: at phase #1 it collects
      rowids of rows to be deleted, then at phase #2 in multi_delete::do_deletes()
      it calls handler->rnd_pos() to read rows to be deleted and deletes them.
      
      The problem occurred when phase #1 used Rowid Filter on the table that
      phase #2 would be deleting from.
      In InnoDB, h->rnd_init(scan=false) and h->rnd_pos() is an index scan over PK
      under the hood. So, at phase #2 ha_innobase::rnd_init() would try to use the
      Rowid Filter and hit an assertion inside ha_innobase::rnd_init().
      
      Note that multi-table UPDATE works similarly but was not affected, because
      patch for MDEV-7487 added code to disable rowid filter for phase #2 in
      multi_update::do_updates().
      
      This patch changes the approach:
      - It makes InnoDB not use Rowid Filter in rnd_pos() scans: it is disabled in
        ha_innobase::rnd_init() and enabled back in ha_innobase::rnd_end().
      - multi_update::do_updates() no longer disables Rowid Filter for phase#2 as
        it is no longer necessary.
      fe41171c
    • Sergei Golubchik's avatar
      Merge branch '11.0' into 11.1 · f0a54120
      Sergei Golubchik authored
      f0a54120
  8. 12 May, 2024 2 commits
    • Sergei Golubchik's avatar
      sporadic failures of galera.galera_sst_mariabackup · 466ae1cf
      Sergei Golubchik authored
      the test failed almost always in release (but not in debug) builds with
      
      --- galera_sst_mariabackup.result
      +++ galera_sst_mariabackup.reject
      @@ -5,7 +5,7 @@
       connection node_1;
       select @@innodb_undo_tablespaces;
       @@innodb_undo_tablespaces
      -0
      +3
       connection node_2;
       select @@innodb_undo_tablespaces;
       @@innodb_undo_tablespaces
      
      and
      
      [Warning] InnoDB: Cannot change innodb_undo_tablespaces=0 because previous shutdown was not with innodb_fast_shutdown=0
      
      because mariadbd *before this test* wasn't using innodb_fast_shutdown=0
      
      Fix the bootstrap to use innodb_fast_shutdown=0 (and the bootstrap
      creates a starting point for any test that uses a .cnf file)
      
      followup for cac0fc97
      
      also, remove redundant include/have_innodb.inc
      466ae1cf
    • Sergei Golubchik's avatar
      Merge branch '10.11' into 11.0 · f9807aad
      Sergei Golubchik authored
      f9807aad
  9. 10 May, 2024 2 commits
  10. 08 May, 2024 9 commits
  11. 07 May, 2024 3 commits
    • Sergei Petrunia's avatar
      MDEV-28621: group by optimization incorrectly removing subquery where subject buried in a function · 40b3525f
      Sergei Petrunia authored
      Workaround patch: Do not remove GROUP BY clause when it has
      subquer(ies) in it.
      
      remove_redundant_subquery_clauses() removes redundant GROUP BY clause
      from queries in form:
        expr IN (SELECT no_aggregates GROUP BY ...)
        expr {CMP} {ALL|ANY|SOME} (SELECT no_aggregates GROUP BY ...)
      This hits problems when the GROUP BY clause itself has subquer(y/ies).
      
      This patch is just a workaround: it disables removal of GROUP BY clause
      if the clause has one or more subqueries in it.
      
      Tests:
      - subselect_elimination.test has all known crashing cases.
      - subselect4.result, insert_select.result are updated.
      Note that in some cases results of SELECT are changed too (not just
      EXPLAINs). These are caused by non-deterministic SQL: when running a
      query like:
      
        x > ANY( SELECT col1 FROM t1 GROUP BY constant_expression)
      
      without removing the GROUP BY, the executor is free to pick the value
      of t1.col1 from any row in the GROUP BY group (denote it $COL1_VAL).
      Then, it computes x > ANY(SELECT $COL1_VAL).
      
      When running the same query and removing the GROUP BY:
      
         x > ANY( SELECT col1 FROM t1)
      
      the executor will actually check all rows of t1.
      40b3525f
    • Monty's avatar
      MDEV-34055 Assertion '...' failure or corruption errors upon REPAIR on Aria tables · ec6aa9ac
      Monty authored
      The problem was two fold:
      - REPAIR TABLE t1 USE_FRM did not work for transactional
        Aria tables (Table was thought to be repaired, which it was not) which
        caused issues in later usage of the table.
      - When swapping tmp_data file to data file, sort_info files where not
        updated. This caused problems if there was several unique keys and
        there was a duplicate for the second key.
      ec6aa9ac
    • Galina Shalygina's avatar
      MDEV-23878 Wrong result with semi-join and splittable derived table · 4bc1860e
      Galina Shalygina authored
      Due to this bug a wrong result might be expected from queries with
      an IN subquery predicate in the WHERE clause and a derived table in the
      FROM clause to which split optimization could be applied.
      
      The function JOIN::fix_all_splittings_in_plan() used the value of the
      bitmap JOIN::sjm_lookup_tables() such as it had been left after the
      search for the best plan for the select containing the splittable
      derived table. That value could not be guaranteed to be correct. So the
      recalculation of this bitmap is needed to exclude the plans with key
      accesses from SJM lookup tables.
      
      Approved by Igor Babaev <igor@maridb.com>
      4bc1860e