1. 14 Dec, 2020 1 commit
  2. 12 Dec, 2020 1 commit
  3. 11 Dec, 2020 1 commit
  4. 09 Dec, 2020 1 commit
    • Oleksandr Byelkin's avatar
      MDEV-19273: Server crash in MDL_ticket::has_stronger_or_equal_type or... · 86fc37b6
      Oleksandr Byelkin authored
      MDEV-19273: Server crash in MDL_ticket::has_stronger_or_equal_type or Assertion `thd->mdl_context.is_lock_owner(MDL_key::TABLE, table->db.str, table->table_name.str, MDL_SHARED)' failed in mysql_rm_table_no_locks
      
      Early report error in case of DROP SEQUENCE <non-sequence>
      
      Do not use error variable for other purposes except error.
      86fc37b6
  5. 07 Dec, 2020 2 commits
  6. 02 Dec, 2020 1 commit
  7. 01 Dec, 2020 5 commits
    • Vlad Lesin's avatar
      MDEV-22929 MariaBackup option to report and/or continue when corruption is encountered · e30a05f4
      Vlad Lesin authored
      Post-push Windows compilation errors fix.
      e30a05f4
    • Monty's avatar
      After merge fixes · 7edfed63
      Monty authored
      Change thd->mdl_context.release_transactional_locks() to
      thd->mdl_release_transactional_locks()
      7edfed63
    • Marko Mäkelä's avatar
      MDEV-24323 Crash on recovery after kill during instant ADD COLUMN · 73f34336
      Marko Mäkelä authored
      row_undo_ins_parse_undo_rec(): Do not try to read non-existing
      virtual column information for the metadata record.
      73f34336
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 81ab9ea6
      Marko Mäkelä authored
      81ab9ea6
    • 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 4 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
      Fixed maria.create test · c5375764
      Monty authored
      c5375764
    • Monty's avatar
    • Varun Gupta's avatar
      MDEV-21265: IN predicate conversion to IN subquery should be allowed for a... · b4379df5
      Varun Gupta authored
      MDEV-21265: IN predicate conversion to IN subquery should be allowed for a broader set of datatype comparison
      
      Allow materialization strategy when collations on the
      inner and outer sides of an IN subquery are the same and the
      character set of the inner side is a proper subset of the character
      set on the outer side.
      This allows conversion from utf8mb3 to utf8mb4
      as the former is a subset of the later.
      This is only allowed when IN predicate is converted to an IN subquery
      
      Backported part of the patch (d6a00d9b) of MDEV-17905.
      b4379df5
  9. 26 Nov, 2020 1 commit
  10. 25 Nov, 2020 5 commits
  11. 24 Nov, 2020 1 commit
  12. 23 Nov, 2020 3 commits
  13. 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
  14. 18 Nov, 2020 2 commits
  15. 17 Nov, 2020 5 commits
  16. 16 Nov, 2020 1 commit
  17. 15 Nov, 2020 1 commit
  18. 14 Nov, 2020 2 commits
  19. 13 Nov, 2020 2 commits