1. 03 Aug, 2022 1 commit
  2. 02 Aug, 2022 3 commits
  3. 01 Aug, 2022 7 commits
    • Aleksey Midenkov's avatar
      MDEV-28727 ALTER TABLE ALGORITHM=NOCOPY does not work after upgrade · 1ea5e402
      Aleksey Midenkov authored
      MDEV-20704 changed the rules of how (HA_BINARY_PACK_KEY |
      HA_VAR_LENGTH_KEY) flags are added. Older FRMs before that fix had
      these flags for DOUBLE index. After that fix when ALTER sees such old
      FRM it thinks it cannot do instant alter because of failed
      compare_keys_but_name(): it compares flags against tmp table created
      by ALTER.
      
      MDEV-20704 fix was actually not about DOUBLE type but about
      FIELDFLAG_BLOB which affected DOUBLE. So there is no direct knowledge
      that any other types were not affected.
      
      The proposed fix under CHECK TABLE checks if FRM has
      (HA_BINARY_PACK_KEY | HA_VAR_LENGTH_KEY) flags and was created prior
      MDEV-20704 and if so issues "needs upgrade". When mysqlcheck and
      mysql_upgrade see such status they issue ALTER TABLE FORCE and upgrade
      the table to the version of server.
      1ea5e402
    • Aleksey Midenkov's avatar
      MDEV-21540 Initialization of already inited long unique index on reorganize partition · 231feabd
      Aleksey Midenkov authored
      Handler for existing partition was already index-inited at the
      beginning of copy_partitions().
      
      In the case of REORGANIZE PARTITION we fill new partition by calling
      its ha_write_row() (handler is storage engine of new partition). From
      that we go through the below conditions:
      
          if (this->inited == RND)
            table->clone_handler_for_update();
          handler *h= table->update_handler ? table->update_handler : table->file;
      
      First, the above misses the meaning of this->inited check. Now it is
      new partition and this handler is not inited. So, we assign
      table->file which is ha_partition and is really not known to be inited
      or not. It is supposed (this == table->file), otherwise we are
      out of the logic for using update_handler. This patch adds DBUG_ASSERT
      for that.
      
      Second, we call check_duplicate_long_entries() for table->file and
      that calls ha_partition::index_init() which calls index_init() for
      each partition's handler. But the existing parititions' handlers was
      already inited in copy_partitions() and we fail on assertion.
      
      The fix implies that we don't need check_duplicate_long_entries()
      per-partition as we've already done check_duplicate_long_entries() for
      ha_partition. For REORGANIZE PARTITION that means existing row was
      already checked at previous INSERT/UPDATE commands, so no need to
      check it again (see NOTE in handler::ha_write_row()).
      
      The fix also optimizes ha_update_row() so
      check_duplicate_long_entries_update() is not called per-partition
      considering it was already called for ha_partition. Besides,
      per-partition duplicate check is not really usable.
      231feabd
    • Julius Goryavsky's avatar
      MDEV-28758: Mariabackup copies binary logs to backup directory · 7fb1f919
      Julius Goryavsky authored
      This commit restores defaults and functionality regarding binlogs
      to the way it was prior to MDEV-27524. The mariabackup utility no
      longer saves binlogs files as part of a backup without the --galera-info
      option. However, since we use --galera-info during SST, the behavior
      of mariabackup changes and, in combination with GTIDs support enabled,
      mariabackup transfers one (most recent) binlog file obtained after
      FLUSH BINARY LOGS. In other cases, binlogs are not transferred during
      SST in mariabackup mode. As for SST in the rsync mode, it works the
      same way as before MDEV-27524 - by default it transfers one last
      binlog file.
      
      The --sst-max-binlogs option for mariabackup and the sst_max_binlogs
      parameter in the [sst] / server sections are no longer supported for
      SST via mariabackup.
      7fb1f919
    • Sergei Golubchik's avatar
      only copy buffer pool dump in SST galera mode · 5b415437
      Sergei Golubchik authored
      and then only into the default name, so that the joiner could find it
      5b415437
    • Sergei Golubchik's avatar
      5197519f
    • Marko Mäkelä's avatar
      MDEV-14804 innodb.update_time occasionally fails · 6a3fbfdb
      Marko Mäkelä authored
      Let simplify the test.
      The update_time is stored in the table metadata (dict_table_t);
      it has nothing to do with buffer pool page eviction or replacement.
      6a3fbfdb
    • Sergei Golubchik's avatar
      in INFORMATION_SCHEMA.ALL_PLUGINS match installed plugins better · 40c2460d
      Sergei Golubchik authored
      look for an installed plugin with the same name _and the same type_
      (in case there are many plugins with the same name and different type,
      which is, technically, possible for built-in plugins).
      40c2460d
  4. 29 Jul, 2022 5 commits
  5. 28 Jul, 2022 1 commit
  6. 27 Jul, 2022 8 commits
    • Oleksandr Byelkin's avatar
      wolfssl v5.4.0-stable · f0107c90
      Oleksandr Byelkin authored
      f0107c90
    • Vladislav Vaintroub's avatar
      Fixes for WolfSSL 5.4.0 · 4329720b
      Vladislav Vaintroub authored
      4329720b
    • Oleksandr Byelkin's avatar
      MDEV-26647 (simple_password_check) Include password validation plugin... · 15a2ff12
      Oleksandr Byelkin authored
      MDEV-26647 (simple_password_check) Include password validation plugin information in the error message if the SQL statement is not satisfied password policy
      
      Make the plugin reporting cause of the error.
      15a2ff12
    • Oleksandr Byelkin's avatar
      MDEV-26647 (plugin name) Include password validation plugin information in the... · cc6bba00
      Oleksandr Byelkin authored
      MDEV-26647 (plugin name) Include password validation plugin information in the error message if the SQL statement is not satisfied password policy
      
      Add plugin name to the error message.
      cc6bba00
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · e5c4f4e5
      Marko Mäkelä authored
      e5c4f4e5
    • Marko Mäkelä's avatar
      MDEV-28495 InnoDB corruption due to lack of file locking · 0ee1082b
      Marko Mäkelä authored
      Starting with commit da094188 (MDEV-24393),
      MariaDB will no longer acquire advisory file locks on InnoDB data
      files by default, because it would create a large number of
      entries in Linux /proc/locks.
      
      The motivation for acquiring the file locks is to prevent accidental
      concurrent startup of multiple server processes on the same data files.
      Such mistake still turns out to be relatively common, based on
      corruption bug reports from the community.
      
      To prevent corruption due to concurrent startup attempts, the
      Aria storage engine would unconditionally acquire an advisory lock
      on one of its log files.
      
      Solution: InnoDB will always lock its system tablespace files.
      (Ever since commit 685d958e
      the InnoDB log file will not necessarily be open while the
      server is running, because it can be accessed via memory-mapped I/O.)
      
      If more protection is desired, then the option --external-locking
      can be used.
      
      The mandatory advisory lock also fixes intermittent failures of
      some crash recovery tests. It turns out that when the mtr test harness
      kills and restarts the server, it will not actually ensure that the
      old process has terminated before starting the new one.
      0ee1082b
    • Oleksandr Byelkin's avatar
      Merge branch '10.3' into 10.4 · 3bb36e94
      Oleksandr Byelkin authored
      3bb36e94
    • Igor Babaev's avatar
      MDEV-29139 Crash when using ANY predicand with redundant subquery in GROUP BY clause · bd935a41
      Igor Babaev authored
      This bug could cause a crash of the server when executing queries containing
      ANY/ALL predicands with redundant subqueries in GROUP BY clauses.
      These subqueries are eliminated by remove_redundant_subquery_clause()
      together with elimination of GROUP BY list containing these subqueries.
      However the references to the elements of the GROUP BY remained in the
      JOIN::all_fields list of the right operand of of the ALL/ANY predicand.
      Later these references confused make_aggr_tables_info() when forming
      proper execution structures after ALL/ANY predicands had been replaced
      with expressions containing MIN/MAX set functions.
      The patch just removes these references from JOIN::all_fields list used
      by the subquery of the ALL/ANY predicand when its GROUP BY clause is
      eliminated.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      bd935a41
  7. 26 Jul, 2022 11 commits
  8. 25 Jul, 2022 4 commits
    • Brandon Nesterenko's avatar
      MDEV-21087/MDEV-21433: ER_SLAVE_INCIDENT arrives at slave without failure specifics · 555c12a5
      Brandon Nesterenko authored
      Problem:
      =======
      
      This patch addresses two issues:
      
       1. An incident event can be incorrectly reported for transactions
      which are rolled back successfully. That is, an incident event
      should only be generated for failed “non-transactional transactions”
      (i.e., those which modify non-transactional tables) because they
      cannot be rolled back.
      
       2. When the mariadb slave (error) stops at receiving the incident
      event there's no description of what led to it. Neither in the event
      nor in the master's error log.
      
      Solution:
      ========
      
      Before reporting an incident event for a transaction, first validate
      that it is “non-transactional” (i.e. cannot be safely rolled back).
      To determine if a transaction is non-transactional,
        lex->stmt_accessed_table(LEX::STMT_WRITES_NON_TRANS_TABLE)
      is used because it is set previously in
      THD::decide_logging_format().
      
      Additionally, when an incident event is written, write an error
      message to the server’s error log to indicate the underlying issue.
      
      Reviewed by:
      ===========
      Andrei Elkin <andrei.elkin@mariadb.com>
      555c12a5
    • Rucha Deodhar's avatar
      This commit is a fixup for MDEV-28762 · 46ff6608
      Rucha Deodhar authored
      46ff6608
    • Marko Mäkelä's avatar
      Fix DBUG_ENTER/return mismatch · f1c8749f
      Marko Mäkelä authored
      Spotted by Thirunarayanan Balathandayuthapani.
      f1c8749f
    • Marko Mäkelä's avatar
      MDEV-28980 InnoDB: Failing assertion: len <= MAX_TABLE_NAME_LEN · 8aa37c26
      Marko Mäkelä authored
      dict_load_foreigns(): Use a correctly sized buffer for the maximum-length
      SYS_FOREIGN.ID. In case of overflow, do not crash the server but instead
      return DB_CORRUPTION.
      8aa37c26