1. 15 Mar, 2018 6 commits
  2. 14 Mar, 2018 5 commits
  3. 13 Mar, 2018 2 commits
    • Daniele Sciascia's avatar
      MDEV-13549 Fix and re-enable MTR test galera.MW-366 · 9953588a
      Daniele Sciascia authored
      Test galera.MW-366 is not deterministic and depends on timing assumptions.
      The test occasionally fails after checking the number of 'system user'
      processes in processlist after changing the value of variable global
      wsrep_slave_threads, like this:
      ```
      SET GLOBAL wsrep_slave_threads = x;
      --sleep 0.5
      SELECT COUNT(*) = x FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'system user';
      ```
      
      The problem is that the number of slave threads is internally adjusted
      'asynchronously', and it may take some time to spawn/kill new threads,
      especially in a heavily loaded system.
      
      This patch removes the '--sleep 0.5' statements from the test and replaces
      those with appropriate wait conditions, like this:
      ```
      SET GLOBAL wsrep_slave_threads = x;
      let $wait_condition = SLECT COUNT(*) = x FROM ...;
      --source include/wait_condition.inc
      ```
      9953588a
    • Alexander Barkov's avatar
  4. 12 Mar, 2018 4 commits
  5. 11 Mar, 2018 1 commit
  6. 09 Mar, 2018 2 commits
  7. 08 Mar, 2018 2 commits
    • Daniele Sciascia's avatar
      MDEV-13549 Wrong usage of mutex 'LOCK_wsrep_thd' and 'LOCK_thd_kill' test galera.MW-286 · a3ba3aab
      Daniele Sciascia authored
      Test MW-286 occasionally failed with error the following message:
      
      ```
      safe_mutex: Found wrong usage of mutex 'LOCK_wsrep_thd' and 'LOCK_thd_kill'
      Mutex currently locked (in reverse order):
      LOCK_thd_kill                     mariadb-server/sql/sql_class.h  line 3535
      LOCK_wsrep_thd                    mariadb-server/sql/wsrep_thd.cc  line 88
      ```
      
      The fix consists in calling thd->reset_killed() in wsrep_mysql_parse() after
      LOCK_wsrep_thd is unlocked. Which avoids the taking locks LOCK_wsrep_thd and
      LOCK_thd_kill in reverse order.
      a3ba3aab
    • Daniele Sciascia's avatar
      MDEV-13549 Fix and re-enable test galera.MW-286 · 0f0776b2
      Daniele Sciascia authored
      This test failed to work properly because the fixes it came
      with were not merged from upstream.
      The test would fail with a spurious ER_LOCK_DEADLOCK error
      for a conflict that happened earlier in the test execution,
      while wsrep is disabled.
      The original fix was to set THD::wsrep_conflict_state only
      if wsrep is enabled (see wsrep_thd_set_conflict_state() in
      sql/wsrep_mysqld.cc)
      0f0776b2
  8. 07 Mar, 2018 1 commit
    • Marko Mäkelä's avatar
      MDEV-14904 Backport innodb_default_row_format · 8ef727b3
      Marko Mäkelä authored
      InnoDB in Debian uses utf8mb4 as default character set since
      version 10.0.20-2. This leads to major pain due to keys longer
      than 767 bytes.
      
      MariaDB 10.2 (and MySQL 5.7) introduced the setting
      innodb_default_row_format that is DYNAMIC by default. These
      versions also changed the default values of the parameters
      innodb_large_prefix=ON and innodb_file_format=Barracuda.
      This would allow longer column index prefixes to be created.
      The original purpose of these parameters was to allow InnoDB
      to be downgraded to MySQL 5.1, which is long out of support.
      
      Every InnoDB version since MySQL 5.5 does support operation
      with the relaxed limits.
      
      We backport the parameter innodb_default_row_format to
      MariaDB 10.1, but we will keep its default value at COMPACT.
      This allows MariaDB 10.1 to be configured so that CREATE TABLE
      is less likely to encounter a problem with the limitation:
      
      	loose_innodb_large_prefix=ON
      	loose_innodb_default_row_format=DYNAMIC
      
      (Note that the setting innodb_large_prefix was deprecated in
      MariaDB 10.2 and removed in MariaDB 10.3.)
      
      The only observable difference in the behaviour with the default
      settings should be that ROW_FORMAT=DYNAMIC tables can be created
      both in the system tablespace and in .ibd files, no matter what
      innodb_file_format has been assigned to. Unlike MariaDB 10.2,
      we are not changing the default value of innodb_file_format,
      so ROW_FORMAT=COMPRESSED tables cannot be created without
      changing the parameter.
      8ef727b3
  9. 04 Mar, 2018 1 commit
  10. 24 Feb, 2018 2 commits
  11. 22 Feb, 2018 3 commits
  12. 21 Feb, 2018 5 commits
  13. 20 Feb, 2018 3 commits
  14. 19 Feb, 2018 2 commits
  15. 18 Feb, 2018 1 commit