1. 11 Dec, 2020 1 commit
  2. 10 Dec, 2020 9 commits
  3. 09 Dec, 2020 1 commit
    • Aleksey Midenkov's avatar
      MDEV-17573 Assertion in federatedx on multi-update · f99abb45
      Aleksey Midenkov authored
      Cause: shared federatedx_io cannot store table-specific data.
      
      Fix: move current row reference `federatedx_io_mysql::current` to
      ha_federatedx.
      
      FederatedX connection (represented by federatedx_io) is stored into
      federatedx_txn::txn_list of per-server connections (see
      federatedx_txn::acquire()). federatedx_txn object is stored into THD
      (see ha_federatedx::external_lock()). When multiple handlers acquire
      FederatedX connection they get single federatedx_io instance. Multiple
      handlers do their operation via federatedx_io_mysql::mark_position()
      and federatedx_io_mysql::fetch_row() in arbitrarty manner. They access
      the same federatedx_io_mysql instance and same MYSQL_ROWS *current
      pointer, so one handler disrupts the work of the other.
      
      Related to "MDEV-14551 Can't find record in table on multi-table update
      with ORDER BY".
      f99abb45
  4. 08 Dec, 2020 1 commit
    • Igor Babaev's avatar
      MDEV-24019 Assertion is hit for query using recursive CTE with no default DB · a3f7f233
      Igor Babaev authored
      When the query using a recursive CTE whose definition contained wildcard
      symbols in the recursive part was processed at the prepare stage an
      assertion was hit if the query was executed without any default database
      set. The failure happened when the function insert_fields() tried to check
      column privileges for the temporary table created for a recursive
      reference to the CTE. No acl checks are needed for any CTE. That's why this
      check should be blocked as well. The patch formulates a stricter condition
      at which this check is to be blocked that covers the case when a query
      using recursive CTEs is executed with no default database set.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      a3f7f233
  5. 07 Dec, 2020 4 commits
  6. 04 Dec, 2020 2 commits
  7. 01 Dec, 2020 2 commits
    • Alexey Botchkov's avatar
      MDEV-24318 server_audit doesn't respect filters for PROXY_CONNECT · 178d32f0
      Alexey Botchkov authored
      events.
      
      The log line should be added behind the filters.
      178d32f0
    • Vlad Lesin's avatar
      MDEV-22929 MariaBackup option to report and/or continue when corruption is encountered · e6b3e38d
      Vlad Lesin authored
      The new option --log-innodb-page-corruption is introduced.
      
      When this option is set, backup is not interrupted if innodb corrupted
      page is detected. Instead it logs all found corrupted pages in
      innodb_corrupted_pages file in backup directory and finishes with error.
      
      For incremental backup corrupted pages are also copied to .delta file,
      because we can't do LSN check for such pages during backup,
      innodb_corrupted_pages will also be created in incremental backup
      directory.
      
      During --prepare, corrupted pages list is read from the file just after
      redo log is applied, and each page from the list is checked if it is allocated
      in it's tablespace or not. If it is not allocated, then it is zeroed out,
      flushed to the tablespace and removed from the list. If all pages are removed
      from the list, then --prepare is finished successfully and
      innodb_corrupted_pages file is removed from backup directory. Otherwise
      --prepare is finished with error message and innodb_corrupted_pages contains
      the list of the pages, which are detected as corrupted during backup, and are
      allocated in their tablespaces, what means backup directory contains corrupted
      innodb pages, and backup can not be considered as consistent.
      
      For incremental --prepare corrupted pages from .delta files are applied
      to the base backup, innodb_corrupted_pages is read from both base in
      incremental directories, and the same action is proceded for corrupted
      pages list as for full --prepare. innodb_corrupted_pages file is
      modified or removed only in base directory.
      
      If DDL happens during backup, it is also processed at the end of backup
      to have correct tablespace names in innodb_corrupted_pages.
      e6b3e38d
  8. 30 Nov, 2020 2 commits
    • Monty's avatar
      MDEV 15532 Assertion `!log->same_pk' failed in row_log_table_apply_delete · 828471cb
      Monty authored
      The reason for the failure is that
      thd->mdl_context.release_transactional_locks()
      was called after commit & rollback even in cases where the current
      transaction is still active.
      
      For 10.2, 10.3 and 10.4 the fix is simple:
      - Replace all calls to thd->mdl_context.release_transactional_locks() with
        thd->release_transactional_locks(). The thd function will only call
        the mdl_context function if there are no active transactional locks.
        In 10.6 we will better fix where we will change the return value for
        some trans_xxx() functions to indicate if transaction did close the
        transaction or not. This will avoid the need of the indirect call.
      
      Other things:
      - trans_xa_commit() and trans_xa_rollback() will automatically
        call release_transactional_locks() if the transaction is closed.
      - We can't do that for the other functions as the caller of many of these
        are doing additional work (like close_thread_tables) before calling
        release_transactional_locks().
      - Added missing abort_result_set() and missing DBUG_RETURN in
        select_create::send_eof()
      - Fixed wrong indentation in injector::transaction::commit()
      828471cb
    • Monty's avatar
  9. 26 Nov, 2020 1 commit
  10. 25 Nov, 2020 3 commits
  11. 23 Nov, 2020 2 commits
  12. 19 Nov, 2020 1 commit
    • Igor Babaev's avatar
      MDEV-19179 Regression: SELECT ... UNION ... with inconsistent column names fails · 1248c654
      Igor Babaev authored
      A bogus error message was issued when a condition was pushed into a
      materialized derived table or view specified as union of selects with
      aggregation when the corresponding columns of the selects had different
      names. This happened because the expression pushed into having clauses of
      the selects was adjusted for the names of the first select of the union.
      The easiest solution was to rename the columns of the other selects to be
      name compatible with the columns of the first select.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      1248c654
  13. 18 Nov, 2020 2 commits
  14. 17 Nov, 2020 5 commits
  15. 15 Nov, 2020 1 commit
  16. 14 Nov, 2020 1 commit
  17. 13 Nov, 2020 2 commits
    • Marko Mäkelä's avatar
      MDEV-24188 Hang in buf_page_create() after reusing a previously freed page · bb328a2a
      Marko Mäkelä authored
      The fix of MDEV-23456 (commit b1009ae5)
      introduced a livelock between page flushing and a thread that is
      executing buf_page_create().
      
      buf_page_create(): If the current mini-transaction is holding
      an exclusive latch on the page, do not attempt to acquire another
      one, and do not care about any I/O fix.
      
      mtr_t::have_x_latch(): Replaces mtr_t::get_fix_count().
      
      dyn_buf_t::for_each_block(const Functor&) const: A new variant.
      
      rw_lock_own(): Add a const qualifier.
      
      Reviewed by: Thirunarayanan Balathandayuthapani
      bb328a2a
    • Igor Babaev's avatar
      MDEV-23619 MariaDB crash on WITH RECURSIVE UNION ALL (CTE) query · 190e8a4c
      Igor Babaev authored
      Due to a premature cleanup of the unit that specified a recursive CTE
      used in the second operand of union the server fell into an infinite
      loop in the reported test case. In other cases this premature cleanup
      could cause other problems.
      The bug is the result of a not quite correct fix for MDEV-17024. The
      unit that specifies a recursive CTE has to be cleaned only after the
      cleanup of the last external reference to this CTE. It means that
      cleanups of the unit triggered not by the cleanup of a external
      reference to the CTE must be blocked.
      Usage of local table chains in selects to get external references to
      recursive CTEs was not correct either because of possible merges of
      some selects.
      
      Also fixed a minor bug in st_select_lex::set_explain_type() that caused
      typing 'RECURSIVE UNION' instead of 'UNION' in EXPLAIN output for external
      references to a recursive CTE.
      190e8a4c