1. 11 Nov, 2020 3 commits
    • sjaakola's avatar
      MDEV-24119 MDL BF-BF Conflict caused by TRUNCATE TABLE · 15401b86
      sjaakola authored
      A follow-up fix, for original fix for MDEV-21577, which did not handle well
      temporary tables.
      
      OPTIMIZE and REPAIR TABLE statements can take a list of tables as argument,
      and some of the tables may be temporary. Proper handling of temporary tables
      is to skip them and continue working on the real tables. The bad version, skipped all tables,
      if a single temporary table was in the argument list. And this resulted so that FK parent
      tables were not scnanned for the remaining real tables. Some mtr tests, using OPTIMIZE or REPAIR
      for temporary tables caused regressions bacause of this, e.g. galera.galera_optimize_analyze_multi
      
      The fix in this PR opens temporary and real tables first, and in the table handling loop skips
      temporary tables, FK parent scanning is done only for real tables.
      
      The test has new scenario for OPTIMIZE and REPAIR issued for two tables of which one is temporary table.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      15401b86
    • sjaakola's avatar
      MDEV-24119 MDL BF-BF Conflict caused by TRUNCATE TABLE · 773e4138
      sjaakola authored
      This PR fixes same issue as MDEV-21577 for TRUNCATE TABLE.
      MDEV-21577 fixed TOI replication for OPTIMIZE, REPAIR and ALTER TABLE
      operating on FK child table. It was later found out that also TRUNCATE
      has similar problem and needs a fix.
      
      The actual fix is to do FK parent table lookup before TRUNCATE TOI
      isolation and append found FK parent table names in certification key
      list for the write set.
      
      PR contains also new test scenario in galera_ddl_fk_conflict test where
      FK child has two FK parent tables and there are two DML transactions operating
      on both parent tables.
      
      For development convenience, new TO isolation macro was added:
      WSREP_TO_ISOLATION_BEGIN_IF and WSREP_TO_ISOLATION_BEGIN_ALTER macro was changed
      to skip the goto statement.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      773e4138
    • Daniele Sciascia's avatar
      Update wsrep-lib · 83f3d12f
      Daniele Sciascia authored
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      83f3d12f
  2. 10 Nov, 2020 2 commits
  3. 08 Nov, 2020 1 commit
  4. 04 Nov, 2020 4 commits
  5. 03 Nov, 2020 7 commits
    • Daniele Sciascia's avatar
      MDEV-24063 Assertion during graceful shutdown with wsrep_on=OFF · 1f1fa07c
      Daniele Sciascia authored
      During graceful shutdowns, client connections are closed and
      eventually and THD::awake() acquires LOCK_thd_data mutex which is
      required later on in wsrep_thd_is_aborting(). Make sure LOCK_thd_data
      is acquired, even if global wsrep_on is disabled.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      1f1fa07c
    • sjaakola's avatar
      MDEV-21577 MDL BF-BF conflict · 4d6c6611
      sjaakola authored
      Some DDL statements appear to acquire MDL locks for a table referenced by
      foreign key constraint from the actual affected table of the DDL statement.
      OPTIMIZE, REPAIR and ALTER TABLE belong to this class of DDL statements.
      
      Earlier MariaDB version did not take this in consideration, and appended
      only affected table in the certification key list in write set.
      Because of missing certification information, it could happen that e.g.
      OPTIMIZE table for FK child table could be allowed to apply in parallel
      with DML operating on the foreign key parent table, and this could lead to
      unhandled MDL lock conflicts between two high priority appliers (BF).
      
      The fix in this patch, changes the TOI replication for OPTIMIZE, REPAIR and
      ALTER TABLE statements so that before the execution of respective DDL
      statement, there is foreign key parent search round. This FK parent search
      contains following steps:
      * open and lock the affected table (with permissive shared locks)
      * iterate over foreign key contstraints and collect and array of Fk parent
        table names
      * close all tables open for the THD and release MDL locks
      * do the actual TOI replication with the affected table and FK parent
        table names as key values
      
      The patch contains also new mtr test for verifying that the above mentioned
      DDL statements replicate without problems when operating on FK child table.
      The mtr test scenario #1, which can be used to check if some other DDL
      (on top of OPTIMIZE, REPAIR and ALTER) could cause similar excessive FK
      parent table locking.
      Reviewed-by: default avatarAleksey Midenkov <aleksey.midenkov@mariadb.com>
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      4d6c6611
    • Daniel Bartholomew's avatar
      bump the VERSION · 5739c770
      Daniel Bartholomew authored
      5739c770
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 533a13af
      Marko Mäkelä authored
      533a13af
    • Marko Mäkelä's avatar
      fixup 67cb7ea2 · 4b3690b5
      Marko Mäkelä authored
      4b3690b5
    • Jan Lindström's avatar
      Clean up wsrep.variables · 67cb7ea2
      Jan Lindström authored
      67cb7ea2
    • Teemu Ollakka's avatar
      MDEV-23872 Crash in galera::TrxHandle::state() · 4489b66a
      Teemu Ollakka authored
      Prepared statements which were run over binary protocol crashed
      a server if the statement did not have CF_PS_ARRAY_BINDING_OPTIMIZED
      flag and the statement was executed in bulk mode and a BF abort occrurred.
      This was because the bulk execution resulted in several statements without
      calling wsrep_after_statement() between, which confused wsrep transaction
      state tracking.
      
      As a fix, call wsrep_after_statement() in bulk loop after each execution
      if CF_PS_ARRAY_BINDING_OPTIMIZED is not set.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      4489b66a
  6. 02 Nov, 2020 7 commits
  7. 01 Nov, 2020 2 commits
  8. 31 Oct, 2020 2 commits
    • Daniel Black's avatar
      MDEV-23630: mysqldump logically dump system table information · d6ea03fa
      Daniel Black authored
      Add --system={all, users, plugins, udfs, servers, stats, timezones}
      
      This will dump system information from the server in
      a logical form like:
      * CREATE USER
      * GRANT
      * SET DEFAULT ROLE
      * CREATE ROLE
      * CREATE SERVER
      * INSTALL PLUGIN
      * CREATE FUNCTION
      
      "stats" is the innodb statistics tables or EITS and
      these are dumped as INSERT/REPLACE INTO statements
      without recreating the table.
      
      "timezones" is the collection of timezone tables
      which are important to transfer to generate identical
      results on restoration.
      
      Two other options have an effect on the SQL generated by
      --system=all. These are mutually exclusive of each other.
      * --replace
      * --insert-ignore
      
      --replace will include "OR REPLACE" into the logical form
      like:
      * CREATE OR REPLACE USER ...
      * DROP ROLE IF EXISTS (MySQL-8.0+)
      * CREATE OR REPLACE ROLE ...
      * UNINSTALL PLUGIN IF EXISTS (10.4+) ... (before INSTALL PLUGIN)
      * DROP FUNCTION IF EXISTS (MySQL-5.7+)
      * CREATE OR REPLACE [AGGREGATE] FUNCTION
      * CREATE OR REPLACE SERVER
      
      --insert-ignore uses the construct " IF NOT EXISTS" where
      supported in the logical syntax.
      
      'CREATE OR REPLACE USER' includes protection against
      being run as the same user that is importing the mysqldump.
      
      Includes experimental support for dumping mysql-5.7/8.0
      system tables and exporting logical SQL compatible with MySQL.
      
      Updates mysqldump man page, including this information and
      (removing obsolute bug reference)
      
      Reviewed-by: anel@mariadb.org
      d6ea03fa
    • Elena Stepanova's avatar
      6d3792a9
  9. 30 Oct, 2020 12 commits
    • Daniel Black's avatar
      MDEV-22974: mysql_native_password make "invalid" valid · 5b779c22
      Daniel Black authored
      Per b9f3f068, mysql_system_tables_data.sql creates
      a mysql_native_password with a salted hash of "invalid" so that `set password`
      will detect a native password can be applied:.
      
      SHOW CREATE USER; diligently uses this value in its output
      generating the SQL:
      
         MariaDB [(none)]> show create user;
      
         +---------------------------------------------------------------------------------------------------+
         | CREATE USER for dan@localhost                                                                     |
         +---------------------------------------------------------------------------------------------------+
         | CREATE USER `dan`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket |
         +---------------------------------------------------------------------------------------------------+
      
      Attempting to execute this before this patch results in:
      
        MariaDB [(none)]>  CREATE USER `dan2`@`localhost` IDENTIFIED VIA mysql_native_password USING 'invalid' OR unix_socket;
        ERROR 1372 (HY000): Password hash should be a 41-digit hexadecimal number
      
      As such, deep the implementation of mysql_native_password we make "invalid" valid (pun intended)
      such that the above create user will succeed. We do this by storing
      "*THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE" (credit: Oracle MySQL), that is of an INCORRECT
      length for a scramble.
      
      In native_password_authenticate we check the length of this cached value
      and immediately fail if it is anything other than the scramble length.
      
      native_password_get_salt is only called in the context of set_user_salt, so all setting of native
      passwords to hashed content of 'invalid', quite literally create an invalid password.
      
      So other forms of "invalid" are valid SQL in creating invalid passwords:
      
         MariaDB [(none)]> set password = 'invalid';
         Query OK, 0 rows affected (0.001 sec)
      
         MariaDB [(none)]> alter user dan@localhost IDENTIFIED BY PASSWORD 'invalid';
         Query OK, 0 rows affected (0.000 sec)
      
      closes #1628
      
      Reviewer: serg@mariadb.com
      5b779c22
    • Oleksandr Byelkin's avatar
      Merge branch '10.2' into 10.3 · 794f6651
      Oleksandr Byelkin authored
      794f6651
    • Marko Mäkelä's avatar
      Update Connector/C · 1fddccf6
      Marko Mäkelä authored
      1fddccf6
    • Marko Mäkelä's avatar
      Try to stabilize main.innodb_ext_key,off · 5b3be9e1
      Marko Mäkelä authored
      Thanks to Varun Gupta for suggesting this. This seems to
      make main.innodb_ext_key,off more stable.
      5b3be9e1
    • Marko Mäkelä's avatar
      MDEV-22387: Static_binary_string::q_append() invokes memcpy on NULL · cb253b86
      Marko Mäkelä authored
      Invoking memcpy() on a NULL pointer is undefined behaviour
      (even if the length is 0) and gives the compiler permission to
      assume that the pointer is nonnull. Recent versions of GCC
      (starting with version 8) are more aggressively optimizing away
      checks for NULL pointers. This undefined behaviour would cause
      a SIGSEGV in the test main.func_encrypt on an optimized debug build
      on GCC 10.2.0.
      cb253b86
    • Marko Mäkelä's avatar
      MDEV-23991 fixup: Initialize the memory · 72eea39d
      Marko Mäkelä authored
      This regression was introduced in
      commit afc9d00c.
      This is a partial backport of
      commit 199863d7 from 10.4.
      72eea39d
    • Marko Mäkelä's avatar
      Update Connector/C · fbcd7c0c
      Marko Mäkelä authored
      fbcd7c0c
    • Varun Gupta's avatar
      MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in... · 5a0c34e4
      Varun Gupta authored
       MDEV-24033: SIGSEGV in __memcmp_avx2_movbe from queue_insert | SIGSEGV in __memcmp_avx2_movbe from native_compare
      
      The issue here was the system variable max_sort_length was being applied
      to decimals and it was truncating the value for decimals to the number
      of bytes set by max_sort_length.
      This was leading to a buffer overflow as the values were written
      to the buffer without truncation and then we moved the offset to
      the number of bytes(set by max_sort_length), that are needed for comparison.
      
      The fix is to not apply max_sort_length for fixed size types like INT,
      DECIMALS and only apply max_sort_length for CHAR, VARCHARS, TEXT and
      BLOBS.
      5a0c34e4
    • Sergei Golubchik's avatar
      Fix RPM packaging on cmake 3.18+ · c7902186
      Sergei Golubchik authored
      cmake has caught up and since version 3.18 it started supporting
      CPACK_RPM_POST_TRANS_SCRIPT_FILE, something we've supported for
      two years and cmake 2.8.11. Both implementation add %posttrans tag
      and rpmbuild gets confused.
      
      Disable our implementation for cmake 3.18+
      c7902186
    • Marko Mäkelä's avatar
      MDEV-23991 fixup: Initialize the memory · 199863d7
      Marko Mäkelä authored
      Also, revert the work-around for the test that was attempted in
      commit 85613a32.
      
      This issue was caught by MemorySanitizer as well as on the
      Microsoft Windows debug builds, thanks to /MD being used
      starting with 10.4.
      
      The code fix will also be applied to 10.2 because the regression
      was introduced in commit afc9d00c.
      199863d7
    • Jan Lindström's avatar
      Fix sporadic test failure on galera_parallel_apply_3nodes. · 5482d627
      Jan Lindström authored
      Test itself is not deterministic.
      5482d627
    • Jan Lindström's avatar
      MDEV-23659: Update Galera disabled.def file · 99362359
      Jan Lindström authored
      Disable galera_var_replicate_myisam until fixed on 10.4
      99362359