1. 28 Jun, 2023 1 commit
  2. 27 Jun, 2023 3 commits
    • Sergei Golubchik's avatar
      mtr: fix the help text for debuggers · d214628a
      Sergei Golubchik authored
      d214628a
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-31086 MODIFY COLUMN can break FK constraints, and lead to unrestorable dumps · 5f09b53b
      Thirunarayanan Balathandayuthapani authored
      - When foreign_key_check is disabled, allowing to modify the
      column which is part of foreign key constraint can lead to
      refusal of TRUNCATE TABLE, OPTIMIZE TABLE later. So it make
      sense to block the column modify operation when foreign key
      is involved irrespective of foreign_key_check variable.
      
      Correct way to modify the charset of the column when fk is involved:
      
      SET foreign_key_checks=OFF;
      ALTER TABLE child DROP FOREIGN KEY fk, MODIFY m VARCHAR(200) CHARSET utf8mb4;
      ALTER TABLE parent MODIFY m VARCHAR(200) CHARSET utf8mb4;
      ALTER TABLE child ADD CONSTRAINT FOREIGN KEY (m) REFERENCES PARENT(m);
      SET foreign_key_checks=ON;
      
      fk_check_column_changes(): Remove the FOREIGN_KEY_CHECKS while
      checking the column change for foreign key constraint. This
      is the partial revert of commit 5f1f2fc0
      and it changes the behaviour of copy alter algorithm
      
      ha_innobase::prepare_inplace_alter_table(): Find the modified
      column and check whether it is part of existing and newly
      added foreign key constraint.
      5f09b53b
    • Yuchen Pei's avatar
      MDEV-29447 MDEV-26285 MDEV-31338 Refactor spider_db_mbase_util::open_item_func · 423c28f0
      Yuchen Pei authored
      spider_db_mbase_util::open_item_func() is a monster function.
      It is difficult to maintain while it is expected that we need to
      modify it when a new SQL function or a new func_type is added.
      
      We split the function into two distinct functions: one handles the
      case of str != NULL and the other handles the case of str == NULL.
      
      This refactoring was done in a conservative way because we do not
      have comprehensive tests on the function.
      
      It also fixes MDEV-29447 and MDEV-31338 where field items that are
      arguments of a func item may be used before created / initialised.
      
      Note this commit is adapted from a patch by Nayuta for MDEV-26285.
      423c28f0
  3. 26 Jun, 2023 1 commit
  4. 22 Jun, 2023 2 commits
  5. 19 Jun, 2023 1 commit
  6. 08 Jun, 2023 2 commits
  7. 07 Jun, 2023 3 commits
  8. 06 Jun, 2023 2 commits
  9. 05 Jun, 2023 2 commits
    • Brandon Nesterenko's avatar
      MDEV-13915: STOP SLAVE takes very long time on a busy system · 0a99d457
      Brandon Nesterenko authored
      The problem is that a parallel replica would not immediately stop
      running/queued transactions when issued STOP SLAVE. That is, it
      allowed the current group of transactions to run, and sometimes the
      transactions which belong to the next group could be started and run
      through commit after STOP SLAVE was issued too, if the last group
      had started committing. This would lead to long periods to wait for
      all waiting transactions to finish.
      
      This patch updates a parallel replica to try and abort immediately
      and roll-back any ongoing transactions. The exception to this is any
      transactions which are non-transactional (e.g. those modifying
      sequences or non-transactional tables), and any prior transactions,
      will be run to completion.
      
      The specifics are as follows:
      
       1. A new stage was added to SHOW PROCESSLIST output for the SQL
      Thread when it is waiting for a replica thread to either rollback or
      finish its transaction before stopping. This stage presents as
      “Waiting for worker thread to stop”
      
       2. Worker threads which error or are killed no longer perform GCO
      cleanup if there is a concurrently running prior transaction. This
      is because a worker thread scheduled to run in a future GCO could be
      killed and incorrectly perform cleanup of the active GCO.
      
       3. Refined cases when the FL_TRANSACTIONAL flag is added to GTID
      binlog events to disallow adding it to transactions which modify
      both transactional and non-transactional engines when the binlogging
      configuration allow the modifications to exist in the same event,
      i.e. when using binlog_direct_non_trans_update == 0 and
      binlog_format == statement.
      
       4. A few existing MTR tests relied on the completion of certain
      transactions after issuing STOP SLAVE, and were re-recorded
      (potentially with added synchronizations) under the new rollback
      behavior.
      
      Reviewed By
      ===========
      Andrei Elkin <andrei.elkin@mariadb.com>
      0a99d457
    • Sergei Petrunia's avatar
      MDEV-31403: Server crashes in st_join_table::choose_best_splitting · 928012a2
      Sergei Petrunia authored
      The code in choose_best_splitting() assumed that the join prefix is
      in join->positions[].
      
      This is not necessarily the case. This function might be called when
      the join prefix is in join->best_positions[], too.
      Follow the approach from best_access_path(), which calls this function:
      pass the current join prefix as an argument,
      "const POSITION *join_positions" and use that.
      928012a2
  10. 04 Jun, 2023 1 commit
  11. 03 Jun, 2023 5 commits
  12. 02 Jun, 2023 9 commits
  13. 01 Jun, 2023 1 commit
  14. 31 May, 2023 2 commits
  15. 27 May, 2023 1 commit
  16. 25 May, 2023 1 commit
  17. 24 May, 2023 1 commit
  18. 22 May, 2023 2 commits
    • Jan Lindström's avatar
      MDEV-30197 : Missing DBUG_RETURN or DBUG_VOID_RETURN macro in function... · 9f909e54
      Jan Lindström authored
      MDEV-30197 : Missing DBUG_RETURN or DBUG_VOID_RETURN macro in function "Wsrep_schema::restore_view()"
      
      Here user is starting server with unsupported client charset.
      We need to create wsrep_schema tables using explicit latin1
      charset to avoid errors in restoring view.
      9f909e54
    • Daniele Sciascia's avatar
      MDEV-30855 Remove test galera.galera_bf_abort_group_commit · 1ac00c5e
      Daniele Sciascia authored
      This test was re-enabled in commit 0174a9ff, and
      has been failing since then.
      The test is configured such that Galera runs with commit ordering
      disabled, a configuration which is which was meant for testing the
      performance penalty of commit ordering (not meant to be used in
      practice).
      Moreover, we have test galera_sr.galera_sr_bf_abort, which is
      identical, but runs with commit ordering enabled.
      No reasons to keep the failing test around.
      1ac00c5e