1. 08 Aug, 2024 4 commits
  2. 07 Aug, 2024 2 commits
    • Nikita Malyavin's avatar
      MDEV-34632 Assertion failed in handler::assert_icp_limitations · 25e2d0a6
      Nikita Malyavin authored
      Assertion `table->field[0]->ptr >= table->record[0] &&
      table->field[0]->ptr <= table->record[0] + table->s->reclength' failed in
      handler::assert_icp_limitations.
      
      table->move_fields has some limitations:
      1. It cannot be used in cascade
      2. It should always have a restoring pair.
      
      Rule 1 is covered by assertions in handler::assert_icp_limitations
      and handler::ptr_in_record (commit 30894fe9).
      
      Rule 2 should be manually maintained with care. Hopefully, the rule 1 assertions
      may sometimes help as well.
      
      In ha_myisam::repair, both rules are broken. table->move_fields is used
      asymmetrically there: it is set on every param->fix_record call
      (i.e. in compute_vcols) but is restored only once, in the end of repair.
      
      The reason to updating field ptr's for every call is that compute_vcols can
      (supposedly) be called in parallel, that is, with the same table, but different
      records.
      
      The condition to "unmove" the pointers in ha_myisam::restore_vcos_after_repair
      is incorrect, when stored vcols are available, and myisam stores a VIRTUAL field
      if it's the only field in the table (the record cannot be of zero length).
      
      This patch solves the problem by "unmoving" the pointers symmetrically, in
      compute_vcols. That is, both rules will be preserved maintained.
      25e2d0a6
    • Yuchen Pei's avatar
  3. 04 Aug, 2024 6 commits
  4. 03 Aug, 2024 1 commit
    • Oleg Smirnov's avatar
      MDEV-34683 Types mismatch when cloning items causes debug assertion · cf202dec
      Oleg Smirnov authored
      New runtime type diagnostic (MDEV-34490) has detected that classes
      Item_func_eq, Item_default_value and Item_date_literal_for_invalid_dates
      incorrectly return an instance of its ancestor classes when being cloned.
      This commit fixes that.
      
      Additionally, it fixes a bug at Item_func_case_simple::do_build_clone()
      which led to an endless loop of cloning functions calls.
      
      Reviewer: Oleksandr Byelkin <sanja@mariadb.com>
      cf202dec
  5. 01 Aug, 2024 2 commits
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-29010 Table cannot be loaded after instant ALTER · 37119cd2
      Thirunarayanan Balathandayuthapani authored
      Reason:
      ======
      - InnoDB fails to load the instant alter table metadata from
      clustered index while loading the table definition.
      The reason is that InnoDB metadata blob has the column length
      exceeds maximum fixed length column size.
      
      Fix:
      ===
      - InnoDB should treat the long fixed length column as variable
      length fields that needs external storage while initializing
      the field map for instant alter operation
      37119cd2
    • Galina Shalygina's avatar
      MDEV-23983: Crash caused by query containing constant having clause · d072a296
      Galina Shalygina authored
      Before this patch the crash occured when a single row dataset is used and
      Item::remove_eq_conds() is called for HAVING. This function is not supposed
      to be called after the elimination of multiple equalities.
      
      To fix this problem instead of Item::remove_eq_conds() Item::val_int() is
      used. In this case the optimizer tries to evaluate the condition for the
      single row dataset and discovers impossible HAVING immediately. So, the
      execution phase is skipped.
      
      Approved by Igor Babaev <igor@maridb.com>
      d072a296
  6. 31 Jul, 2024 2 commits
    • Brandon Nesterenko's avatar
      MDEV-15393: Fix rpl_mysqldump_gtid_slave_pos · 001608de
      Brandon Nesterenko authored
      The slave would try to sync_with_master_gtid.inc,
      but the master never actually saved its gtid position
      so the test would move on too quickly.
      001608de
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-34670 IMPORT TABLESPACE unnecessary traverses tablespace list · 533e6d5d
      Thirunarayanan Balathandayuthapani authored
      Problem:
      ========
      - After the commit ada1074b (MDEV-14398)
      fil_crypt_set_encrypt_tables() iterates through all tablespaces to
      fill the default_encrypt tables list. This was a trigger to
      encrypt or decrypt when key rotation age is set to 0. But import
      tablespace does call fil_crypt_set_encrypt_tables() unnecessarily.
      The motivation for the call is to signal the encryption threads.
      
      Fix:
      ====
      ha_innobase::discard_or_import_tablespace: Remove the
      fil_crypt_set_encrypt_tables() and add the import tablespace
      to the default encrypt list if necessary
      533e6d5d
  7. 30 Jul, 2024 2 commits
  8. 29 Jul, 2024 3 commits
    • Rex's avatar
      MDEV-34506 2nd execution name resolution problem with pushdown into unions · 48b256a7
      Rex authored
      Statements affected by this bug need all the following to be true
      1) a derived table table or view whose specification contains a set
           operation at the top level.
      2) a grouping operator (group by/having) operating on a column alias
           other than in the first select of the union/intersect
      3) an outer condition that will be pushed into all selects in this
           union/intersect, either into the where or having clause
      
      When pushing a condition into all selects of a unit with more than one
      select, pushdown_cond_for_derived() renames items so we can re-use the
      condition being pushed.
      These names need to be saved and reset for correct name resolution on
      second execution of prepared statements.
      
      Reviewed by Igor Babaev (igor@mariadb.com)
      48b256a7
    • Marko Mäkelä's avatar
      MDEV-34502 fixup: Do not cripple MSAN · 7e5c9ccd
      Marko Mäkelä authored
      We need to work around deficiencies of Valgrind, and apparently
      the previous work-around attempts
      (such as d247d649) do not work
      anymore, definitely not on recent clang-based compilers.
      
      MemorySanitizer should be fine; unfortunately we set HAVE_valgrind for it
      as well.
      7e5c9ccd
    • Marko Mäkelä's avatar
      MDEV-34565: SIGILL due to OS not supporting AVX512 · 232d7a5e
      Marko Mäkelä authored
      It is not sufficient to check that the CPU supports the necessary
      instructions. Also the operating system (or virtual machine hypervisor)
      must enable all the AVX registers to be saved and restored on a
      context switch.
      
      Because clang 8 does not support the compiler intrinsic _xgetbv()
      we will require clang 9 or later for enabling the use of VPCLMULQDQ
      and the related AVX512 features.
      232d7a5e
  9. 27 Jul, 2024 1 commit
  10. 25 Jul, 2024 1 commit
  11. 24 Jul, 2024 1 commit
  12. 23 Jul, 2024 1 commit
    • Oleg Smirnov's avatar
      MDEV-34634 Types mismatch when cloning items causes debug assertion · c91aeb37
      Oleg Smirnov authored
      New runtime diagnostic introduced with MDEV-34490 has detected
      that `Item_int_with_ref` incorrectly returns an instance of its ancestor
      class `Item_int`. This commit fixes that.
      
      In addition, this commit reverts a part of the diagnostic related
      to `clone_item()` checks. As it turned out, `clone_item()` is not required
      to return an object of the same class as the cloned one. For example,
      look at `Item_param::clone_item()`: it can return objects of `Item_null`,
      `Item_int`, `Item_string`, etc, depending on the object state.
      So the runtime type diagnostic is not applicable to `clone_item()` and
      is disabled with this commit.
      
      As the similar diagnostic failures are expected to appear again
      in the future, this commit introduces a new test file in the main suite:
      item_types.test, and new test cases may be added to this file
      
      Reviewer: Oleksandr Byelkin <sanja@mariadb.com>
      c91aeb37
  13. 19 Jul, 2024 2 commits
    • Andrei's avatar
      MDEV-15393 gtid_slave_pos duplicate key errors after mysqldump restore · b8f92ade
      Andrei authored
      When mysqldump is run to dump the `mysql` system database, it generates
      INSERT statements into the table `mysql.gtid_slave_pos`.
      After running the backup script
      those inserts did not produce the expected gtid state on slave. In
      particular the maximum of mysql.gtid_slave_pos.sub_id did not make
      into
         rpl_global_gtid_slave_state.last_sub_id
      
      an in-memory object that is supposed to match the current state of the
      table. And that was regardless of whether --gtid option was specified
      or not. Later when the backup recipient server starts as slave
      in *non-gtid* mode this desychronization may lead to a duplicate key
      error.
      
      This effect is corrected for --gtid mode mysqldump/mariadb-dump only
      as the following.  The fixes ensure the insert block of the dump
      script is followed with a "summing-up" SET @global.gtid_slave_pos
      assignment.
      
      For the implemenation part, note a deferred print-out of
      SET-gtid_slave_pos and associated comments is prefered over relocating
      of the entire blocks if (opt_master,slave_data &&
      do_show_master,slave_status) ...  because of compatiblity
      concern. Namely an error inside do_show_*() is handled in the new code
      the same way, as early as, as before.
      
      A regression test can be run in how-to-reproduce mode as well.
      One affected mtr test observed.
      rpl_mysqldump_slave.result "mismatch" shows now the new deferring print
      of SET-gtid_slave_pos policy in action.
      b8f92ade
    • Oleksandr Byelkin's avatar
      Fix view protocol · b8b6cab2
      Oleksandr Byelkin authored
      b8b6cab2
  14. 18 Jul, 2024 1 commit
  15. 17 Jul, 2024 11 commits