1. 27 Mar, 2024 13 commits
  2. 25 Mar, 2024 2 commits
  3. 22 Mar, 2024 2 commits
  4. 19 Mar, 2024 1 commit
  5. 18 Mar, 2024 3 commits
    • Daniel Black's avatar
      MDEV-33636: RPM caps is on mariadbd exe · a13e521b
      Daniel Black authored
      Postfix on 51e3f1da that
      mariadbd should be the executable name rather than capabilities
      on a symlink.
      a13e521b
    • Marko Mäkelä's avatar
      Work around missing MSAN instrumentation · 4592af2e
      Marko Mäkelä authored
      Let us skip the recently added test main.mysql-interactive if
      an instrumented ncurses library is not available.
      
      In InnoDB, let us work around an uninstrumented libnuma, by
      declaring that the objects returned by numa_get_mems_allowed()
      are initialized.
      4592af2e
    • Marko Mäkelä's avatar
      MDEV-33478: Tests massively fail with clang-18 -fsanitize=memory · 09d991d0
      Marko Mäkelä authored
      Starting with clang-16, MemorySanitizer appears to check that
      uninitialized values not be passed by value nor returned.
      Previously, it was allowed to copy uninitialized data in such cases.
      
      get_foreign_key_info(): Remove a local variable that was passed
      uninitialized to a function.
      
      DsMrr_impl: Initialize key_buffer, because DsMrr_impl::dsmrr_init()
      is reading it.
      
      test_bind_result_ext1(): MYSQL_TYPE_LONG is 32 bits, hence we must
      use a 32-bit type, such as int. sizeof(long) differs between
      LP64 and LLP64 targets.
      09d991d0
  6. 15 Mar, 2024 2 commits
  7. 14 Mar, 2024 5 commits
  8. 13 Mar, 2024 4 commits
  9. 12 Mar, 2024 1 commit
    • Dmitry Shulga's avatar
      MDEV-33549: Incorrect handling of UPDATE in PS mode in case a table's colum declared as NOT NULL · 428a6731
      Dmitry Shulga authored
      UPDATE statement that is run in PS mode and uses positional parameter
      handles columns declared with the clause DEFAULT NULL incorrectly in
      case the clause DEFAULT is passed as actual value for the positional
      parameter of the prepared statement. Similar issue happens in case
      an expression specified in the DEFAULT clause of table's column definition.
      
      The reason for incorrect processing of columns declared as DEFAULT NULL
      is that setting of null flag for a field being updated was missed
      in implementation of the method Item_param::assign_default().
      The reason for incorrect handling of an expression in DEFAULT clause is
      also missed saving of a field inside implementation of the method
      Item_param::assign_default().
      428a6731
  10. 11 Mar, 2024 5 commits
  11. 08 Mar, 2024 1 commit
    • Daniele Sciascia's avatar
      MDEV-33540 Avoid writes to TRX_SYS page during mariabackup operations · 648d2da8
      Daniele Sciascia authored
      Fix a scenario where `mariabackup --prepare` fails with assertion
      `!m_modifications || !recv_no_log_write'  in `mtr_t::commit()`. This
      happens if the prepare step of the backup encounters a data directory
      which happens to store wsrep xid position in TRX SYS page (this is no
      longer the case since 10.3.5). And since MDEV-17458,
      `trx_rseg_array_init()` handles this case by copying the xid position
      to rollback segments, before clearing the xid from TRX SYS page.
      However, this step should be avoided when `trx_rseg_array_init()` is
      invoked from mariabackup. The relevant code was surrounded by the
      condition `srv_operation == SRV_OPERATION_NORMAL`. An additional check
      ensures that we are not trying to copy a xid position which has
      already zeroed.
      648d2da8
  12. 07 Mar, 2024 1 commit
    • mariadb-DebarunBanerjee's avatar
      MDEV-33593 Auto increment deadlock error causes ASSERT in subsequent save point · afe96329
      mariadb-DebarunBanerjee authored
      The issue here is ha_innobase::get_auto_increment() could cause a
      deadlock involving auto-increment lock and rollback the transaction
      implicitly. For such cases, storage engines usually call
      thd_mark_transaction_to_rollback() to inform SQL engine about it which
      in turn takes appropriate actions and close the transaction. In innodb,
      we call it while converting Innodb error code to MySQL.
      
      However, since ::innobase_get_autoinc() returns void, we skip the call
      for error code conversion and also miss marking the transaction for
      rollback for deadlock error. We assert eventually while releasing a
      savepoint as the transaction state is not active.
      
      Since convert_error_code_to_mysql() is handling some generic error
      handling part, like invoking the callback when needed, we should call
      that function in ha_innobase::get_auto_increment() even if we don't
      return the resulting mysql error code back.
      afe96329