1. 14 Mar, 2024 8 commits
  2. 13 Mar, 2024 10 commits
  3. 12 Mar, 2024 4 commits
    • Monty's avatar
      MDEV-33622 Server crashes when the UPDATE statement (which has duplicate key)... · cfa8268e
      Monty authored
      MDEV-33622 Server crashes when the UPDATE statement (which has duplicate key) is run after setting a low thread_stack
      
      This was caused by wrong allocation of variable on stack.
      (Was allocating 4K of data instead of 512 bytes).
      
      No test case as the original MDEV test cases is not usable for mtr.
      cfa8268e
    • 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
    • Marko Mäkelä's avatar
      MDEV-24167 fixup: Stricter assertion · 4ac8c4c8
      Marko Mäkelä authored
      log_free_check(): Assert that the current thread is not holding
      lock_sys.latch in any mode.
      
      This fixes up commit 5f2dcd11
      4ac8c4c8
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · c3a00dfa
      Marko Mäkelä authored
      c3a00dfa
  4. 11 Mar, 2024 5 commits
  5. 09 Mar, 2024 1 commit
  6. 08 Mar, 2024 3 commits
    • 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
    • Monty's avatar
      MDEV-33623 Partitioning is broken on big endian architectures · f838b2d7
      Monty authored
      MDEV-33502 Slowdown when running nested statement with many partitions
      caused this error as I failed to take into account bigendian architectures.
      
      This patch also introduces bitmap_import() and bitmap_export() to be used
      when one wants to store bitmaps in files/logs in a portable way.
      Reviewed-by: default avatarKristian Nielsen <knielsen@knielsen-hq.org>
      f838b2d7
    • Monty's avatar
      MDEV-33620 Improve times and states in show processlist for replication · 9a132d42
      Monty authored
      This will makes it easier to find out what replication workers are
      doing and what they are waiting for.
      
      Things changed in processlist:
      - Slave_SQL time was not consistent. Now time for state "Slave has
        read all relay log; waiting for more updates" shows how long it has
        waited for getting the next event.
      - Slave_worker threads did often show "Closing tables" for a long
        time.  Now the state is reverted to the previous state after
        "Closing tables" is done.
      - Commit and Rollback states where not shown for replication (and some
        other threads). Now Commit and Rollback states are always shown and
        the state is reverted to previous state when the Commit/Rollback
        have finished.
      
      Code changes:
      - Added thd->set_time_for_next_stage() for parallel replication when
        when starting to wait for prior transactions to commit, group commit,
        and FTWRL and for free space in thread pool.
        Before we reset the time only after the above events.
      - Moved THD_STAGE_INFO(stage_rollback) and THD_STAGE_INFO(stage_commit)
        from sql_parse.cc to transaction.cc to ensure this is done for
        all commits and not only 'normal connection queries'.
      
      Test case changes:
      - close_thread_tables() reverting stage to previous stage caused the
        counter in performance_schema to be increased. In many case it is
        the 'sql/starting' stage that was effected.
      - We only change to "Commit" stage if there is a need for a commit.
        This caused some "Commit" stages to disapper from perfschema reports.
      
      TODO in 11.#:
      - Slave_IO always showes "Waiting for master to send event" and the time is
        from SLAVE START. We should in 11.# change this to be the time since
        reading the last event.
      9a132d42
  7. 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
  8. 06 Mar, 2024 4 commits
  9. 05 Mar, 2024 1 commit
    • Monty's avatar
      MDEV-33582 Add more warnings to be able to better diagnose network issues · 567c0973
      Monty authored
      Warnings are added to net_server.cc when
      global_system_variables.log_warnings >= 4.
      
      When the above condition holds then:
      - All communication errors from net_serv.cc is also written to the
        error log.
      - In case of a of not being able to read or write a packet, a more
        detailed error is given.
      
      Other things:
      - Added detection of slaves that has hangup to Ack_receiver::run()
      - vio_close() is now first marking the socket closed before closing it.
        The reason for this is to ensure that the connection that gets a read
        error can check if the reason was that the socket was closed.
      - Add a new state to vio to be able to detect if vio is acive, shutdown or
        closed. This is used to detect if socket is closed by another thread.
      - Testing of the new warnings is done in rpl_get_lock.test
      - Suppress some of the new warnings in mtr to allow one to run some of
        the tests with -mysqld=--log-warnings=4. All test in the 'rpl' suite
        can now be run with this option.
       - Ensure that global.log_warnings are restored at test end in a way
         that allows one to use mtr --mysqld=--log-warnings=4.
      
      Reviewed-by: <serg@mariadb.org>,<brandon.nesterenko@mariadb.com>
      567c0973
  10. 04 Mar, 2024 2 commits
  11. 03 Mar, 2024 1 commit