1. 09 Jun, 2021 3 commits
    • Vladislav Vaintroub's avatar
      Remove WolfSSL workaround for old version. · dbe3161b
      Vladislav Vaintroub authored
      We're already on 4.4.6
      dbe3161b
    • Marko Mäkelä's avatar
      Merge 10.3 to 10.4 · c7ee039d
      Marko Mäkelä authored
      c7ee039d
    • Marko Mäkelä's avatar
      MDEV-25886 CHECK TABLE crash with DB_MISSING_HISTORY if innodb_read_only · 75a65d32
      Marko Mäkelä authored
      Occasionally, the test innodb.alter_copy would fail in MariaDB 10.6.1,
      reporting DB_MISSING_HISTORY during CHECK TABLE. It started to occur during
      the development of MDEV-25180, which introduced purge_sys.stop_SYS().
      If we delay purge more during DDL operations, then the test would
      almost always fail. The reason is that during startup we will restore
      a purge view, and CHECK TABLE would still use REPEATABLE READ
      even though innodb_read_only is set and other isolation levels
      than READ UNCOMMITTED are not guaranteed to work.
      
      ha_innobase::check(): Use READ UNCOMMITTED isolation level if
      innodb_read_only is set or innodb_force_recovery exceeds 3.
      
      dict_set_corrupted(): Do not update the persistent data dictionary
      if innodb_force_recovery exceeds 3.
      75a65d32
  2. 08 Jun, 2021 5 commits
  3. 07 Jun, 2021 1 commit
  4. 06 Jun, 2021 2 commits
    • Otto Kekäläinen's avatar
      Revert "CONNECT: move jar files to /usr/share and include them in DEBs" · 3c922d6d
      Otto Kekäläinen authored
      This partially reverts commit d7321893.
      
      The *.jar files are not being built and all Debian builds are failing
      as dh_install stops on missing files. To build them we would need to also
      add new Java build dependencies.
      
      In a stable release (10.2->10.5) we shouldn't add new files and certainly
      not any new build dependencies, so reverting commit.
      
      Also, the files are located in a different path, and already included
      in the mariadb-test-data package:
      
        /usr/share/mysql/mysql-test/plugin/connect/connect/std_data/JavaWrappers.jar
        /usr/share/mysql/mysql-test/plugin/connect/connect/std_data/JdbcMariaDB.jar
        /usr/share/mysql/mysql-test/plugin/connect/connect/std_data/Mongo2.jar
        /usr/share/mysql/mysql-test/plugin/connect/connect/std_data/Mongo3.jar
      
      This change needs to be redesigned and applies only on 10.6 or newer.
      3c922d6d
    • Vladislav Vaintroub's avatar
      MDEV-23815 Windows : mysql_upgrade_wizard fails, if service name has spaces · 9f9a925c
      Vladislav Vaintroub authored
      The fix is to quote service name parameter, when it is passed to
      mysql_upgrade_service subprocess.
      9f9a925c
  5. 05 Jun, 2021 1 commit
  6. 04 Jun, 2021 6 commits
  7. 03 Jun, 2021 2 commits
    • Igor Babaev's avatar
      MDEV-25714 Join using derived with aggregation returns incorrect results · 0b797130
      Igor Babaev authored
      If a join query uses a derived table (view / CTE) with GROUP BY clause then
      the execution plan for such join may employ split optimization. When this
      optimization is employed the derived table is not materialized. Rather only
      some partitions of the derived table are subject to grouping. Split
      optimization can be applied only if:
      - there are some indexes over the tables used in the join specifying the
        derived table whose prefixes partially cover the field items used in the
        GROUP BY list (such indexes are called splitting indexes)
      - the WHERE condition of the join query contains conjunctive equalities
        between columns of the derived table that comprise major parts of
        splitting indexes and columns of the other join tables.
      
      When the optimizer evaluates extending of a partial join by the rows of the
      derived table it always considers a possibility of using split optimization.
      Different splitting indexes can be used depending on the extended partial
      join. At some rare conditions, for example, when there is a non-splitting
      covering index for a table joined in the join specifying the derived table
      usage of a splitting index to produce rows needed for grouping may be still
      less beneficial than usage of such covering index without any splitting
      technique. The function JOIN_TAB::choose_best_splitting() must take this
      into account.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      0b797130
    • Igor Babaev's avatar
      MDEV-25714 Join using derived with aggregation returns incorrect results · 663bc849
      Igor Babaev authored
      If a join query uses a derived table (view / CTE) with GROUP BY clause then
      the execution plan for such join may employ split optimization. When this
      optimization is employed the derived table is not materialized. Rather only
      some partitions of the derived table are subject to grouping. Split
      optimization can be applied only if:
      - there are some indexes over the tables used in the join specifying the
        derived table whose prefixes partially cover the field items used in the
        GROUP BY list (such indexes are called splitting indexes)
      - the WHERE condition of the join query contains conjunctive equalities
        between columns of the derived table that comprise major parts of
        splitting indexes and columns of the other join tables.
      
      When the optimizer evaluates extending of a partial join by the rows of the
      derived table it always considers a possibility of using split optimization.
      Different splitting indexes can be used depending on the extended partial
      join. At some rare conditions, for example, when there is a non-splitting
      covering index for a table joined in the join specifying the derived table
      usage of a splitting index to produce rows needed for grouping may be still
      less beneficial than usage of such covering index without any splitting
      technique. The function JOIN_TAB::choose_best_splitting() must take this
      into account.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      663bc849
  8. 02 Jun, 2021 7 commits
  9. 01 Jun, 2021 2 commits
  10. 31 May, 2021 2 commits
    • Julius Goryavsky's avatar
      MDEV-25818: RSYNC SST failed due to busy port · 2fb44078
      Julius Goryavsky authored
      This commit reduces the likelihood of getting a busy port on
      quick restarts with rsync SST (problem MDEV-25818) and fixes
      a number of other flaws in SST scripts, adds new functionality,
      and also synchronizes the xtrabackup-v2 script with the
      mariabackup script (the latter applies only to the 10.2 branch):
      
       1) SST via rsync: rsync and stunnel does not always get the right
          time to complete by correctly handling SIGTERM. These utilities
          are now given more time to complete normally (via normal SIGTERM
          processing) before we move on to using "kill -9";
       2) SST via rsync: attempts to terminate an rsync or stunnel process
          (via "kill" utility) are only made if it did not terminated on
          its own;
       3) SST via rsync: if a combination of stunnel and rsync is used,
          then we need to wait for both utilities to finish or stop, not
          just one of them;
       4) The config file and pid file for stunnel are now deleted after
          successful completion of SST on the donor node;
       5) The configs and pid files from rsync and stunnel should not be
          deleted unless these utilities succeed (or are sucessfully
          terminated) on the joiner node;
       6) The configs and pid files now excluded from transfer via rsync;
       7) Spaces in paths are now valid for config files as well (when
          used with SST via rsync or mariabackup / xtrabackup[-v2]);
       8) SST via mariabackup: added preliminary verification of keys and
          certificates that are used when establishing a connection using
          SSL (to avoid long timeouts and improve diagnostics) - by analogy
          with how it is done for the xtrabackup-v2 (plus check for CA file),
          while that check is skipped if the user does not have openssl
          installed (or does not have diff utility);
       9) Added backup-threads=<n> configuration option which adds
          "--parallel=<n>" for mariabackup / xtrabackup at backup and
          move-back stages;
      10) Added encrypt-threads and encrypt-chunk-size configuration
          options for xbcrypt management (when xbcrypt is used);
      11) Small optimization: checking the socat version and adding
          a file with parameters for 2048-bit Diffie-Hellman (if necessary)
          is done only if the user has not specified "dhparam=" in the
          "sockopt" option value;
      12) SST via rsync now supports "backup-threads" configuration option
          (in server-related sections or in the "[sst]");
      13) Determining the number of available processors is now supported
          for FreeBSD + mariabackup/xtrabackup: before that we might have
          problems with "--compact" (rebuild indexes) or qpress on FreeBSD;
      14) The check_pid() function should not raise an error state in
          the rare cases when the pid file was created, but it is empty,
          or if it is deleted right during the check, or when zero is read
          from the pid file;
      15) Iproved templates that are used to check if a requested socket
          is "listening" when using the ss utility;
      16) Shortened some other templates for socket state utilities;
      17) Temporary files created by mariabackup / xtrabackup are moved
          to a separate subdirectory inside tmpdir (so they don't get
          mixed with other temporary files, which can make debugging
          more difficult);
      18) 10.2 only: the script for SST via xtrabackup-v2 has been brought
          in full compliance with all the bugfixes made for mariabackup (as
          it previously contained many flaws compared to the updated script
          for mariabackup).
      2fb44078
    • Vladislav Vaintroub's avatar
  11. 30 May, 2021 1 commit
    • Dmitry Shulga's avatar
      MDEV-25576: The statement EXPLAIN running as regular statement and as prepared... · 91bde0fb
      Dmitry Shulga authored
      MDEV-25576: The statement EXPLAIN running as regular statement and as prepared statement produces different results for UPDATE with subquery
      
      Both EXPLAIN and EXPLAIN EXTENDED statements produce different results set
      in case it is run in normal way and in PS mode for the statements
      UPDATE/DELETE with subquery.
      
      The use case below reproduces the issue:
      MariaDB [test]> CREATE TABLE t1 (c1 INT KEY) ENGINE=MyISAM;
      Query OK, 0 rows affected (0,128 sec)
      
      MariaDB [test]> CREATE TABLE t2 (c2 INT) ENGINE=MyISAM;
      Query OK, 0 rows affected (0,023 sec)
      
      MariaDB [test]> CREATE TABLE t3 (c3 INT) ENGINE=MyISAM;
      Query OK, 0 rows affected (0,021 sec)
      
      MariaDB [test]> EXPLAIN EXTENDED UPDATE t3 SET c3 =
          -> ( SELECT COUNT(d1.c1) FROM ( SELECT a11.c1 FROM t1 AS a11
          -> STRAIGHT_JOIN t2 AS a21 ON a21.c2 = a11.c1 JOIN t1 AS a12
          -> ON a12.c1 = a11.c1 ) d1 );
      +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+
      | id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                          |
      +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+
      |    1 | PRIMARY     | t3    | ALL  | NULL          | NULL | NULL    | NULL |    0 |   100.00 |                                |
      |    2 | SUBQUERY    | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | Impossible WHERE noticed after reading const tables
      +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+
      2 rows in set (0,002 sec)
      
      MariaDB [test]> PREPARE stmt FROM
          -> EXPLAIN EXTENDED UPDATE t3 SET c3 =
          -> ( SELECT COUNT(d1.c1) FROM ( SELECT a11.c1 FROM t1 AS a11
          -> STRAIGHT_JOIN t2 AS a21 ON a21.c2 = a11.c1 JOIN t1 AS a12
          -> ON a12.c1 = a11.c1 ) d1 );
      Query OK, 0 rows affected (0,000 sec)
      Statement prepared
      
      MariaDB [test]>  EXECUTE stmt;
      +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+
      | id   | select_type | table | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra                          |
      +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+
      |    1 | PRIMARY     | t3    | ALL  | NULL          | NULL | NULL    | NULL |    0 |   100.00 |                                |
      |    2 | SUBQUERY    | NULL  | NULL | NULL          | NULL | NULL    | NULL | NULL |     NULL | no matching row in const table |
      +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+
      2 rows in set (0,000 sec)
      
      The reason by that different result sets are produced is that on execution
      of the statement 'EXECUTE stmt' the flag SELECT_DESCRIBE not set
      in the data member SELECT_LEX::options for instances of SELECT_LEX that
      correspond to subqueries used in the UPDTAE/DELETE statements.
      
      Initially, these flags were set on parsing the statement
        PREPARE stmt FROM "EXPLAIN EXTENDED UPDATE t3 SET ..."
      but latter they were reset before starting real execution of
      the parsed query during handling the statement 'EXECUTE stmt';
      
      So, to fix the issue the functions mysql_update()/mysql_delete()
      have been modified to set the flag SELECT_DESCRIBE forcibly
      in the data member SELECT_LEX::options for the primary SELECT_LEX
      of the UPDATE/DELETE statement.
      91bde0fb
  12. 27 May, 2021 5 commits
  13. 26 May, 2021 3 commits