1. 04 Oct, 2021 6 commits
  2. 03 Oct, 2021 1 commit
  3. 02 Oct, 2021 1 commit
  4. 01 Oct, 2021 1 commit
    • mkaruza's avatar
      MDEV-22708 Assertion `!mysql_bin_log.is_open() ||... · 86a2e2ba
      mkaruza authored
      MDEV-22708 Assertion `!mysql_bin_log.is_open() || thd.is_current_stmt_binlog_format_row()' failed in Delayed_insert::handle_inserts and in Diagnostics_area::set_eof_status
      
      Variable wsrep_forced_binlog_format has higher priority than
      binlog_format. In situation where STATEMENT is used and DELAYED INSERT
      is executing we should fall back to non-delay INSERT.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      86a2e2ba
  5. 30 Sep, 2021 5 commits
    • mkaruza's avatar
      MDEV-25883 Galera Cluster hangs while "DELETE FROM mysql.wsrep_cluster" · 2f5ae0da
      mkaruza authored
      Using `innodb_thread_concurrency` will call `wsrep_thd_is_aborting` to
      check WSREP thread state. This call should be protected by taking
      `LOCK_thd_data` before entering function.
      Applier and TOI threads should no be affected with usage of
      `innodb_thread_concurrency` variable so returning before any checks.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      2f5ae0da
    • sjaakola's avatar
      MDEV-24978 crash with transaction on table with no PK and long fulltext column · d5a15f04
      sjaakola authored
      If a table has no unique indexes, write set key information will be collected on all columns in the table.
      The write set key information has space only for max 3500 bytes for individual column, and if a varchar colummn of such non-primary key table is longer than
       this limit, currently a crash follows.
      The fix in this commit, is to truncate key values extracted from such long varhar columns to max 3500 bytes.
      This may potentially lead to false positive certification failures for transactions, which operate on separate cluster nodes, and update/insert/delete table rows, which differ only in the part of such long columns after 3500 bytes border.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      d5a15f04
    • Marko Mäkelä's avatar
      MDEV-25215 Excessive logging "InnoDB: Cannot close file" · be803f03
      Marko Mäkelä authored
      In commit 45ed9dd9 (MDEV-23855)
      when removing fil_system.LRU we failed to rate-limit the output
      for reporting violations of innodb_open_files or open_files_limit.
      
      If the server is run with a small limit of open files that is
      well below the number of .ibd files that are being accessed by
      the workload, and if at the same time innodb_log_file_size is
      very small so that log checkpoints will occur frequently,
      the process of enforcing the open files limit may be run very often.
      
      fil_space_t::try_to_close(): Display at most one message per call,
      and only if at least 5 seconds have elapsed since the last time a
      message was output.
      
      fil_node_open_file(): Only output a summary message if
      fil_space_t::try_to_close() displayed a message during this run.
      (Note: multiple threads may execute fil_node_open_file() on
      different files at the same time.)
      
      fil_space_t::get(): Do not dereference a null pointer if n & STOPPING.
      This was caught by the test case below.
      
      Unfortunately, it is not possible to create a fully deterministic
      test case (expecting exactly 1 message to be emitted). The following with
      --innodb-open-files=10 --innodb-log-file-size=4m
      would occasionally fail to find the message in the log:
      
      --source include/have_innodb.inc
      --source include/have_partition.inc
      --source include/have_sequence.inc
      
      call mtr.add_suppression("InnoDB: innodb_open_files=10 is exceeded");
      
      CREATE TABLE t1 (pk INT AUTO_INCREMENT PRIMARY KEY) ENGINE=InnoDB
      PARTITION BY key (pk) PARTITIONS 100;
      
      INSERT INTO t1 SELECT * FROM seq_1_to_100;
      --disable_query_log
      let $n=400;
      while ($n)
      {
      BEGIN; DELETE FROM t1; ROLLBACK;
      dec $n;
      }
      --enable_query_log
      
      let SEARCH_FILE= $MYSQLTEST_VARDIR/log/mysqld.1.err;
      let SEARCH_PATTERN= \[Note\] InnoDB: Cannot close file;
      -- source include/search_pattern_in_file.inc
      
      DROP TABLE t1;
      be803f03
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · 064cb58e
      Marko Mäkelä authored
      FIXME: Part of the MDEV-20699 test is disabled due to
      nonderterministic result.
      064cb58e
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 57fdd016
      Marko Mäkelä authored
      57fdd016
  6. 29 Sep, 2021 7 commits
  7. 28 Sep, 2021 1 commit
  8. 27 Sep, 2021 6 commits
    • Vladislav Vaintroub's avatar
      MDEV-20699 mysqldump of routines causes MariaDB to get killed by oom-killer · 1f099418
      Vladislav Vaintroub authored
      The reason for this behavior is that SP get cached, per connection.
      The stored_program_cache is size of this cache, which amounts to 256
      routines by default. A compiled stored procedure can easily be several
      megabytes in size. Thus calling SHOW CREATE PROCEDURE for all stored
      procedures, like mysqldump does, can require significant amount of memory.
      
      Fixed by bypassing the cache for "SHOW CREATE". This should normally be
      fine also perfomance-wise, as cache is meant to be used for repeated
      execution, not repeated SHOW CREATEs.
      
      Added a test to verify that CREATE PROCEDURE + SHOW CREATE PROCEURE do not
      cache, i.e amount of allocated memory does not change.
      
      Note, there is a change in existing behavior in an edge case :
      If "SHOW CREATE PROCEDURE p1" called from p1, after p1 was altered, now
      this will now return altered code. Previour behavior - relied on caching
      and would return old code. The previous behavior might was not necessarily
      correct.
      1f099418
    • Jan Lindström's avatar
      MDEV-21613 : galera_sr.GCF-1018B MTR failed: Failed to open table... · 690c4725
      Jan Lindström authored
      MDEV-21613 : galera_sr.GCF-1018B MTR failed: Failed to open table mysql.wsrep_streaming_log for writing
      
      Query can be bf aborted already earlier and then we should not
      even try to open table.
      690c4725
    • Jan Lindström's avatar
      MDEV-21806 : galera.galera_partition MTR failed: failed to recover from DONOR state · 05abcd7e
      Jan Lindström authored
      Add wait_condition to wait until all nodes are in cluster
      05abcd7e
    • Jan Lindström's avatar
      e55c303c
    • Oleksandr Byelkin's avatar
      MDEV-24454 Crash at change_item_tree · 3690c549
      Oleksandr Byelkin authored
      Use in_sum_func (and so nest_level) only in LEX to which SELECT lex belong to
      
      Reduce usage of current_select (because it does not always point on the correct
       SELECT_LEX, for example with prepare.
      
      Change context for all classes inherited from Item_ident (was only for Item_field) in case of pushing down it to HAVING.
      
      Now name resolution context have to have SELECT_LEX reference if the context is present.
      
      Fixed feedback plugin stack usage.
      3690c549
    • Jan Lindström's avatar
  9. 24 Sep, 2021 12 commits