1. 02 Jan, 2021 2 commits
  2. 29 Dec, 2020 2 commits
  3. 28 Dec, 2020 5 commits
    • Teemu Ollakka's avatar
      MDEV-24255 MTR test galera_bf_abort fails with --ps-protocol · 4601e6e5
      Teemu Ollakka authored
      Under ps-protocol, commandsl like COM_STMT_FETCH, COM_STMT_CLOSE and
      COM_STMT_SEND_LONG_DATA are not supposed to return errors. Therefore,
      if a transaction is BF aborted and the client is processing one of
      those commands, then we should not return a deadlock error
      immediately. Instead wait for the a subsequent client interaction
      which permits errors to be returned. To handle this,
      wsrep_before_command() now accepts parameter keep_command_error. If
      set true, keep_command_error will cause wsrep-lib side to skip result
      handling, and to keep the current error for the next interaction with
      the client.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      4601e6e5
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · a64cb6d2
      Marko Mäkelä authored
      a64cb6d2
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 7f037b8c
      Marko Mäkelä authored
      7f037b8c
    • Marko Mäkelä's avatar
      MDEV-24449 Corruption of system tablespace or last recovered page · 5b9ee8d8
      Marko Mäkelä authored
      This corresponds to 10.5 commit 39378e13.
      
      With a patched version of the test innodb.ibuf_not_empty (so that
      it would trigger crash recovery after using the change buffer),
      and patched code that would modify the os_thread_sleep() in
      recv_apply_hashed_log_recs() to be 1ms as well as add a sleep of
      the same duration to the end of recv_recover_page() when
      recv_sys->n_addrs=0, we can demonstrate a race condition.
      
      After disabling some debug checks in buf_all_freed_instance(),
      buf_pool_invalidate_instance() and buf_validate(), we managed to
      trigger an assertion failure in fseg_free_step(), on the XDES_FREE_BIT.
      In other words, an trx_undo_seg_free() call during
      trx_rollback_resurrected() was attempting a double-free of a page.
      This was repeated about once in 400 to 500 test runs. With the fix
      applied, the test passed 2,000 runs.
      
      recv_apply_hashed_log_recs(): Do not only wait for recv_sys->n_addrs
      to reach 0, but also wait for buf_get_n_pending_read_ios() to reach 0,
      to guarantee that buf_page_io_complete() will not be executing
      ibuf_merge_or_delete_for_page().
      5b9ee8d8
    • sjaakola's avatar
      MDEV-23851 MDEV-24229 BF-BF conflict issues · 8e3e87d2
      sjaakola authored
      Issues MDEV-23851 and MDEV-24229 are probably duplicates and are caused by the new self-asserting function lock0lock.cc:wsrep_assert_no_bf_bf_wait().
      The criteria for asserting is too strict and does not take in consideration scenarios of "false positive" lock conflicts, which are resolved by replaying the local transaction.
      As a fix, this PR is relaxing the assert criteria by two conditions, which skip assert if high priority transactions are locking in correct order or if conflicting high priority lock holder is aborting and has just not yet released the lock.
      
      Alternative fix would be to remove wsrep_assert_no_bf_bf_wait() altogether, or remove the assert in this function and let it only print warnings in error log.
      But in my high conflict rate multi-master test scenario, this relaxed asserting appears to be safe.
      
      This PR also removes two wsrep_report_bf_lock_wait() calls in innodb lock manager, which cause mutex access assert in debug builds.
      
      Foreign key appending missed handling of data types of float and double in INSERT execution. This is not directly related to the actual issue here but is fixed in this PR nevertheless. Missing these foreign keys values in certification could cause problems in some multi-master load scenarios.
      
      Finally, some problem reports suggest that some of the issues reported in MDEV-23851 might relate to false positive lock conflicts over unique secondary index gaps. There is separate work for relaxing UK index gap locking of replication appliers, and separate PR will be submitted for it, with a related mtr test as well.
      8e3e87d2
  4. 25 Dec, 2020 1 commit
  5. 24 Dec, 2020 4 commits
  6. 23 Dec, 2020 4 commits
  7. 22 Dec, 2020 7 commits
    • Sergei Petrunia's avatar
      8d8370e3
    • Sergei Petrunia's avatar
      MDEV-24444: ASAN use-after-poison in Item_func_in::get_func_mm_tree with NOT IN · df4f4bd8
      Sergei Petrunia authored
      Fix a trivial error in the fix for MDEV-21958: check the key in the right
      table.
      df4f4bd8
    • Daniele Sciascia's avatar
      MENT-1047 Assertion `active() == false' failed with "XA START.." · 04741dc7
      Daniele Sciascia authored
      Galera replication does not support XA transactions yet. Reject any
      attempt to `XA START` a transaction, if Galera is enabled.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      04741dc7
    • Aleksey Midenkov's avatar
      MDEV-23446 UPDATE does not insert history row if the row is not changed · 9b38ed4c
      Aleksey Midenkov authored
      Add history row outside of compare_record() check. For TRX_ID
      versioning we have to fail can_compare_record to force InnoDB update
      which adds history row; and there in ha_innobase::update_row() is
      additional "row changed" check where we force history row anyway.
      9b38ed4c
    • Aleksey Midenkov's avatar
      MDEV-23644 Assertion on evaluating foreign referential action for... · 932ec586
      Aleksey Midenkov authored
      MDEV-23644 Assertion on evaluating foreign referential action for self-reference in system versioned table
      
      First part of the fix (row0mysql.cc) addresses external columns when adding history
      row on referential action. The full data must be retrieved before the
      row is inserted.
      
      Second part of the fix (the rest) avoids duplicate primary key error between
      the history row generated on referential action and the history row
      generated by SQL command. Both command and referential action can
      happen on same table since foreign key can be self-reference (parent
      and child tables are same). Moreover, the self-reference can refer
      multiple rows when the key is non-unique. In such case history is
      generated by referential action occured on first row but processed all
      rows by a matched key. The second round is when the next row is
      processed by a command but history already exists. In such case we
      check TRX_ID of existing history row and if it is the same we assume
      the above situation and skip adding one more history row or failing
      the command.
      932ec586
    • Aleksey Midenkov's avatar
      MDEV-21138 Assertion `col->ord_part' or `f.col->ord_part' failed in row_build_index_entry_low · 7410ff43
      Aleksey Midenkov authored
      First part (row0mysql.cc) fixes ins_node_set_new_row() usage workflow
      as it is designed to operate on empty row (see row_get_prebuilt_insert_row()
      for example).
      
      Second part (row0ins.cc) fixes duplicate key error in FTS_DOC_ID_INDEX
      since history rows must not generate entries in that index. We detect
      FTS_DOC_ID_INDEX by a number of attributes and skip it if the row is
      historical.
      
      Misc fixes:
      
      row_build_index_entry_low() does not accept non-NULL tuple
      for FTS index (subject assertion fails), assertion (index->type !=
      DICT_FTS) adds code understanding.
      
      Now as historical_row is copied in row_update_vers_insert() there is
      no need to copy the row twice: ROW_COPY_POINTERS is used to build
      historical_row initially.
      
      dbug_print_rec() debug functions.
      7410ff43
    • Aleksey Midenkov's avatar
      MDEV-22178 Assertion `info->alias.str' failed in... · d4258f3a
      Aleksey Midenkov authored
      MDEV-22178 Assertion `info->alias.str' failed in partition_info::check_partition_info instead of ER_VERS_WRONG_PARTS
      
      Assign create_info->alias for ALTER TABLE since it is NULL and later
      accessed for printing error message.
      d4258f3a
  8. 21 Dec, 2020 1 commit
  9. 19 Dec, 2020 6 commits
    • Sergei Golubchik's avatar
      MDEV-22630 mysql_upgrade (MariaDB 5.2.X --> MariaDB 10.3.X) does not fix... · dfe8ef8b
      Sergei Golubchik authored
      MDEV-22630 mysql_upgrade (MariaDB 5.2.X --> MariaDB 10.3.X) does not fix auth_string to change it to authentication_string
      
      cherry-pick from 10.4:
      
        commit b976b9bf
        Author: Sergei Golubchik <serg@mariadb.com>
        Date:   Tue Apr 21 18:40:15 2020 +0200
      
          MDEV-21244 mysql_upgrade creating empty global_priv table
      
          support upgrades from 5.2 privilege tables
      dfe8ef8b
    • Sergei Golubchik's avatar
      Item_func_like::walk() was ignoring escape_item · 6f40d5c8
      Sergei Golubchik authored
      in particular, it caused escape_item->is_expensive() property
      to be lost instead of being properly propagated up.
      6f40d5c8
    • Sergei Golubchik's avatar
      MDEV-24346 valgrind error in main.precedence · 59211ab7
      Sergei Golubchik authored
      Part II.
      
      It's still possible to bypass Item_func_like::escape
      initialization in Item_func_like::fix_fields().
      
      This requires ESCAPE argument being a cacheable subquery
      that uses tables and is inside a derived table which
      is used in multi-update.
      
      Instead of implementing a complex or expensive fix for
      this particular ridiculously artificial case, let's simply disallow it.
      59211ab7
    • Sergei Golubchik's avatar
      MDEV-24346 valgrind error in main.precedence · a587ded2
      Sergei Golubchik authored
      in queries like
      
        create view v1 as select 2 like 1 escape (3 in (select 0 union select 1));
        select 2 union select * from v1;
      
      Item_func_like::escape was left uninitialized, because
      Item_in_optimizer is const_during_execution()
      but not actually const_item() during execution.
      
      It's not, because const subquery evaluation was disabled for derived.
      Practically it only needs to be disabled for multi-update
      that runs fix_fields() before all tables are locked.
      a587ded2
    • Sergei Golubchik's avatar
      Item_func_like calls escape_item->fix_fields() twice · 5785de72
      Sergei Golubchik authored
      this happens if Item_func_like is copied (get_copy()).
      after one copy gets fixed, the other tries to fix escape item again.
      5785de72
    • Jan Lindström's avatar
      MDEV-23065 : Crash after setting wsrep_on to ON dynamically and reconnect · d1e9a4c1
      Jan Lindström authored
      At end_connection make sure we have wsrep before trying to free
      connection assigned to it.
      d1e9a4c1
  10. 18 Dec, 2020 2 commits
    • Alice Sherepa's avatar
      MDEV-22008 rpl.rpl_semi_sync fails in bb, MDEV-24418 reenable... · 4e43e2f9
      Alice Sherepa authored
      MDEV-22008 rpl.rpl_semi_sync fails in bb, MDEV-24418 reenable binlog_truncate_innodb and binlog_spurious_ddl_errors, rpl_parallel_retry fails in bb
      4e43e2f9
    • Nikita Malyavin's avatar
      MDEV-24041 Generated column DELETE with FOREIGN KEY crash InnoDB · 83d2e084
      Nikita Malyavin authored
      row_upd_clust_step() calls row_upd_del_mark_clust_rec() which would
      allocate some memory in row_ins_foreign_fill_virtual(). Then,
      row_upd_store_row() would access the allocated memory, but only after
      potentially freeing that memory by invoking mem_heap_empty(),
      leading to ASAN heap-use-after-free diagnostics.
      
      row_ins_foreign_fill_virtual(): Use a more appropriate memory heap with a
      longer lifetime.
      83d2e084
  11. 17 Dec, 2020 4 commits
    • Igor Babaev's avatar
      MDEV-20751 Permission Issue With Nested CTEs · 25d6f634
      Igor Babaev authored
      Due to this bug the server reported bogus messages about lack of SELECT
      privileges for base tables used in the specifications of CTE tables.
      It happened only if such a CTE were referred to at least twice.
      For any non-recursive reference to CTE that is not primary the
      specification of the CTE is cloned. The function check_table_access() is
      called for such reference. The function checks privileges of the tables
      referenced in the specification. As no name resolution was performed for
      CTE references whose definitions occurred outside the specification before
      the call of check_table_access() that was supposed to check the access
      rights of the underlying tables these references were considered
      as references to base tables rather than references to CTEs. Yet for CTEs
      as well as for derived tables no privileges are needed and thus cannot
      be granted.
      The patch ensures proper name resolution of all references to CTEs before
      any acl checks.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      25d6f634
    • sjaakola's avatar
      MDEV-24327 wsrep XID checkpointing order with log_slave_updates=OFF · 2cb5fb60
      sjaakola authored
      If log_slave_updates==OFF, wsrep applier threads used to be configured
      with option: thd->variables.option_bits&= ~(OPTION_BIN_LOG);
      (i.e. like sql_log_bin=ON). And this was regardless of log-bin configuration.
      
      With this, having configuration of: --log-bin && --log-slave-updates=OFF,
      local threads used binlogging, but applier threads did not. And further:
      local threads went through binlog group commit, while applier threads did
      direct commits. This resulted in situation, where applier threads entered
      earlier in wsrep XID checkpointing, and could sync their wsrep XID out of order.
      Later local thread commit would see that higher seqno was already checkpointed,
      and fire an assert because of this.
      
      As a fix, applier threads are now forced to enable binlogging regardless of
      log-slave-updates configuration.
      
      This PR comes with new mtr test: galera.MDEV-24327, which causes a scenario
      where applier transaction is applied and committed while earlier local transaction
      is parked before commit order monitor enter. A buggy mariadb versoin would fail
      for assertion because of wsrep XID checkpoint order violation.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      2cb5fb60
    • sjaakola's avatar
      MDEV-24327 wsrep XID checkpointing order violation with cert failures · 41a961d8
      sjaakola authored
      Handling of write sets, which fail in certification happens differently than
      with write sets which pass certification. When certification fails, the
      write set applying can be skipped and applier needs only to take care of
      wsrep XID checkpointing. With current implementation, this can rush ahead
      of wsrep XID checkpointing of successful write sets.
      
      The fix in this PR registers wsrep XID checkpointing of certification failure cases in group commit,
      which guarantees that XID ceckpointing order is synchronized with real committing transactions.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      41a961d8
    • sjaakola's avatar
      MDEV-24327 wsrep XID checkpointing order with log_slave_updates=OFF · 87fa6d2c
      sjaakola authored
      If log_slave_updates==OFF, wsrep applier threads used to be configured
      with option: thd->variables.option_bits&= ~(OPTION_BIN_LOG);
      (i.e. like sql_log_bin=ON). And this was regardless of log-bin configuration.
      
      With this, having configuration of: --log-bin && --log-slave-updates=OFF,
      local threads used binlogging, but applier threads did not. And further:
      local threads went through binlog group commit, while applier threads did
      direct commits. This resulted in situation, where applier threads entered
      earlier in wsrep XID checkpointing, and could sync their wsrep XID out of order.
      Later local thread commit would see that higher seqno was already checkpointed,
      and fire an assert because of this.
      
      As a fix, applier threads are now forced to enable binlogging regardless of
      log-slave-updates configuration.
      
      This PR comes with new mtr test: galera.MDEV-24327, which causes a scenario
      where applier transaction is applied and committed while earlier local transaction
      is parked before commit order monitor enter. A buggy mariadb versoin would fail
      for assertion because of wsrep XID checkpoint order violation.
      87fa6d2c
  12. 16 Dec, 2020 2 commits
    • Igor Babaev's avatar
      MDEV-23406 Signal 8 in maria_create after recursive cte query · a244be70
      Igor Babaev authored
      This bug could cause a crash when executing queries that used mutually
      recursive CTEs with system variable big_tables set to 1. It happened due
      to several bugs in the code that handled recursive table references
      referred mutually recursive CTEs. For each recursive table reference a
      temporary table is created that contains all rows generated for the
      corresponding recursive CTE table on the previous step of recursion.
      This temporary table should be created in the same way as the temporary
      table created for a regular materialized derived table using the
      method select_union::create_result_table(). In this case when the
      temporary table is created it uses the select_union::TMP_TABLE_PARAM
      structure as the parameter for the table construction. However the
      code created the temporary table using just the function create_tmp_table()
      and passed pointers to certain fields of the TMP_TABLE_PARAM structure
      used for accumulation of rows of the recursive CTE table as parameters
      for update. This was a mistake because now different temporary tables
      cannot share some TMP_TABLE_PARAM fields in a general case. Besides,
      depending on how mutually recursive CTE tables were defined and which
      of them were referred in the executed query the select_union object
      allocated for a recursive table reference could be allocated again after
      the the temporary table had been created. In this case the TMP_TABLE_PARAM
      object associated with the temporary table created for the recursive
      table reference contained unassigned fields needed for execution when
      Aria engine is employed as the engine for temporary tables.
      This patch ensures that
      - select_union object is created only once for any recursive table
        reference
      - any temporary table created for recursive CTEs uses its own
        TMP_TABLE_PARAM structure
      The patch also fixes a problem caused by incomplete cleanup of join tables
      associated with recursive table references.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      a244be70
    • Stepan Patryshev's avatar
      c742346e