1. 11 Nov, 2020 3 commits
  2. 10 Nov, 2020 4 commits
  3. 09 Nov, 2020 5 commits
    • Marko Mäkelä's avatar
      MDEV-24096 InnoDB assertion 'first_free <= srv_page_size - 8' · a0536d42
      Marko Mäkelä authored
      MDEV-23672 (commit 7eda5561)
      introduced a regression that can corrupt not only undo log pages,
      but anything that resides in the InnoDB buffer pool.
      
      trx_undo_left(): Add debug assertions for the assumptions.
      If the pointer is out of bounds, we will return a positive
      number, not a negative one. Thus, once a page overflow occurs,
      further overflow to adjacent pages will be allowed.
      This allows us to remove some more relaxed debug assertions
      from some callers.
      
      trx_undo_log_v_idx(): Correctly calculate the size limit.
      a0536d42
    • Sergei Golubchik's avatar
      Merge branch '10.2' into 10.3 · 212d92ad
      Sergei Golubchik authored
      212d92ad
    • Igor Babaev's avatar
      MDEV-23811: With large number of indexes optimizer chooses an inefficient plan · bea84aef
      Igor Babaev authored
      This bug could manifest itself for a query with WHERE condition containing
      top level OR formula such that each conjunct contained a single-range
      condition supported by the same index. One of these range conditions must
      be fully covered by another range condition that is used later in the OR
      formula. Additionally at least one of these condition should be ANDed with
      a sargable range condition supported by a different index.
      
      There were several attempts to fix related problems for OR conditions after
      the backport of range optimizer code from MySQL (commit
      0e19f3e3). Unfortunately the first of these
      fixes contained typo remained unnoticed until recently. This typo bug led
      to rejection of valid range accesses. This patch fixed this typo bug.
      The fix revealed another two bugs: one in a constructor for SEL_ARG,
      the other in the function tree_or(). Both are fixed in this patch.
      bea84aef
    • Sergei Petrunia's avatar
      MDEV-24117: Memory management problem ...: Add a testcase · 1404f3be
      Sergei Petrunia authored
      Add a testcase.
      1404f3be
    • Sergei Petrunia's avatar
      MDEV-24117: Memory management problem in statistics state for ... IN · f81eef62
      Sergei Petrunia authored
      Part#1: Revert the patch that caused it:
      
      commit 291be494
      Author: Igor Babaev <igor@askmonty.org>
      Date:   Thu Sep 24 22:02:00 2020 -0700
      
          MDEV-23811: With large number of indexes optimizer chooses an inefficient plan
      f81eef62
  4. 08 Nov, 2020 1 commit
  5. 05 Nov, 2020 2 commits
  6. 04 Nov, 2020 4 commits
  7. 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
  8. 02 Nov, 2020 7 commits
  9. 01 Nov, 2020 3 commits
  10. 31 Oct, 2020 3 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
    • Oleksandr Byelkin's avatar
      Merge branch '10.3' into 10.4 · 80c951ce
      Oleksandr Byelkin authored
      80c951ce
    • Elena Stepanova's avatar
      6d3792a9
  11. 30 Oct, 2020 1 commit
    • 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