1. 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
  2. 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
  3. 10 May, 2024 2 commits
  4. 08 May, 2024 9 commits
  5. 07 May, 2024 9 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
    • Yuchen Pei's avatar
      MDEV-34036 Reset spider_hton_ptr in spider_db_done() · 10a75992
      Yuchen Pei authored
      Otherwise spider_direct_sql may still think the spider plugin is
      available even after spider_db_done() was called.
      10a75992
    • Sergei Golubchik's avatar
      42c99ef0
    • Sergei Golubchik's avatar
      Revert "MDEV-19949 mariabackup option of '--password' or '-p' without... · 421eeb18
      Sergei Golubchik authored
      Revert "MDEV-19949 mariabackup option of '--password' or '-p' without specifying password in commandline"
      
      This reverts commit 91fb8b7f.
      
      Incompatible change, see tests in the next commit
      421eeb18
    • Kristian Nielsen's avatar
      Merge 10.6 to 10.11 · 383ee364
      Kristian Nielsen authored
      383ee364
    • Jan Lindström's avatar
      MDEV-33898 : Galera test failure on galera.MW-369 · 33e4fbf0
      Jan Lindström authored
      Additional changes for the galera_vote_rejoin_ddl test (for 10.5+).
      Signed-off-by: default avatarJulius Goryavsky <julius.goryavsky@mariadb.com>
      33e4fbf0
    • Yuchen Pei's avatar
      MDEV-34098 source start_slave.inc in spider suites · bca366e4
      Yuchen Pei authored
      The spider suite should --source include/start_slave.inc to make sure
      the slave is up before proceeding.
      bca366e4
  6. 06 May, 2024 13 commits