1. 09 Mar, 2022 1 commit
    • Otto Kekäläinen's avatar
      Fix failing Gitlab-CI by adding pcre2-devel as a build dependency · ffb7f885
      Otto Kekäläinen authored
      The commits a73acf6c and
      4d74bac8 updated the PCRE library to a new
      version, which in turn requires CMake 3.0. That does not exist in CentOS 7
      nor 8, so builds started failing.
      
      Actually the build should not be downloading anything at all. The root
      cause was that pcre2-devel was missing from the dependencies. This was
      originally not detected, as the download fallback had masked the issue.
      ffb7f885
  2. 08 Mar, 2022 3 commits
  3. 07 Mar, 2022 7 commits
    • Vlad Lesin's avatar
      Merge 10.5 into 10.6 · 202316a3
      Vlad Lesin authored
      202316a3
    • Vlad Lesin's avatar
      Merge 10.4 into 10.5 · 0b92c7b0
      Vlad Lesin authored
      0b92c7b0
    • Vlad Lesin's avatar
      Merge 10.3 into 10.4 · 1ec32057
      Vlad Lesin authored
      1ec32057
    • Vlad Lesin's avatar
      MDEV-27992 DELETE fails to delete record after blocking is released · 86c1bf11
      Vlad Lesin authored
      MDEV-27025 allows to insert records before the record on which DELETE is
      locked, as a result the DELETE misses those records, what causes serious ACID
      violation.
      
      Revert MDEV-27025, MDEV-27550. The test which shows the scenario of ACID
      violation is added.
      86c1bf11
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · 2dce3bad
      Marko Mäkelä authored
      2dce3bad
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 7b97020d
      Marko Mäkelä authored
      7b97020d
    • Daniel Black's avatar
      MDEV-27891: SIGSEGV in InnoDB buffer pool resize · b6a24724
      Daniel Black authored
      During an increase in resize, the new curr_size got a value
      less than old_size.
      
      As n_chunks_new and n_chunks have a strong correlation to the
      resizing operation in progress, we can use them and remove the
      need for old_size.
      
      For convienece the n_chunks_new < n_chunks is now the is_shrinking
      function.
      
      The volatile compiler optimization on n_chunks{,_new} is removed
      as real mutex uses are needed.
      
      Other n_chunks_new/n_chunks methods:
      
      n_chunks_new and n_chunks almost always read and altered under
      the pool mutex.
      
      Exceptions are:
      * i_s_innodb_buffer_page_fill,
      * buf_pool_t::is_uncompressed (via is_blocked_field)
      These need reexamining for the need of a mutex, however comments
      indicates this already.
      
      get_n_pages has uses in buffer pool load, recover log memory
      exhaustion estimates and innodb status so take the minimum number
      of chunks for safety.
      
      The buf_pool_t::running_out function also uses curr_size/old_size.
      We replace this hot function calculation with just n_chunks_new.
      This is the new size of the chunks before the resizing occurs.
      
      If we are resizing down, we've already got the case we had previously
      (as the minimum). If we are resizing upwards, we are taking an
      optimistic view that there will be buffer chunks available for locks.
      As this memory allocation is occurring immediately next the resizing
      function it seems likely.
      
      Compiler hint UNIV_UNLIKELY removed to leave it to the branch
      predictor to make an informed decision.
      
      Added test case of a smaller size than the Marko/Roel original
      in JIRA reducing the size to 256M. SEGV hits roughly 1/10 times
      but its better than a 21G memory size.
      
      Reviewer: Marko
      b6a24724
  4. 04 Mar, 2022 3 commits
  5. 03 Mar, 2022 4 commits
  6. 01 Mar, 2022 11 commits
  7. 28 Feb, 2022 10 commits
    • Monty's avatar
      Fixed sporadic error in main.backup_locks · 72437cbc
      Monty authored
      The follwoing could happen if InnoDB did some background work while
      test was running:
      
      @@ -5,6 +5,8 @@
       SELECT LOCK_MODE, LOCK_TYPE, TABLE_SCHEMA, TABLE_NAME FROM information_schema.metadata_lock_info;
       LOCK_MODE      LOCK_TYPE       TABLE_SCHEMA    TABLE_NAME
       MDL_SHARED_HIGH_PRIO   Table metadata lock     test    t1
      +MDL_SHARED     Table metadata lock     mysql   innodb_table_stats
      +MDL_SHARED     Table metadata lock     mysql   innodb_index_stat
      72437cbc
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · edb311ae
      Marko Mäkelä authored
      edb311ae
    • Marko Mäkelä's avatar
      MDEV-27964: Work around SIGSEGV in WITH_MSAN builds · bc020058
      Marko Mäkelä authored
      We will move all tests of the ENCRYPT() function to the test
      main.func_crypt, which will be disabled in MSAN builds for now.
      bc020058
    • Marko Mäkelä's avatar
      Merge fixup: -Wconversion · 08d39bdf
      Marko Mäkelä authored
      In merge cc1d9062 the 32-bit builds
      were broken.
      08d39bdf
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · 5c21cba6
      Marko Mäkelä authored
      5c21cba6
    • Marko Mäkelä's avatar
      Avoid some failures WITH_MSAN · 13076bd3
      Marko Mäkelä authored
      13076bd3
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · cc1d9062
      Marko Mäkelä authored
      cc1d9062
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 3c58cdd9
      Marko Mäkelä authored
      3c58cdd9
    • Marko Mäkelä's avatar
      MDEV-27800: Avoid garbage TRX_UNDO_TRX_NO on TRX_UNDO_CACHED pages · 0635088d
      Marko Mäkelä authored
      In commit c7d04487 (MDEV-15132)
      MariaDB Server 10.3 stopped writing the latest transaction identifier
      to the TRX_SYS page. Instead, the transaction identifier will be
      recovered from undo log pages.
      
      Unfortunately, before commit 3926673c
      and mysql/mysql-server@dc29792ff2996aefbb6e64bb2f0bc3aa8fc879e9
      (MySQL 5.1.48 or MariaDB 5.1.48) InnoDB did not always initialize all
      data fields, but some garbage could be left behind in unused parts
      of data pages.
      
      In undo log pages that are essentially free, but added to a list for
      reuse (TRX_UNDO_CACHED) the TRX_UNDO_TRX_NO fields could contain garbage,
      instead of 0. As long as such undo pages are being reused and never
      marked completely free, the garbage contents may remain forever.
      In fact, the function trx_undo_header_create() and the record
      MLOG_UNDO_HDR_CREATE will only initialize TRX_UNDO_TRX_ID, but leave
      TRX_UNDO_TRX_NO uninitialized.
      
      trx_undo_mem_create_at_db_start(): Only read the TRX_UNDO_TRX_NO
      fields of TRX_UNDO_CACHED pages if the TRX_UNDO_PAGE_TYPE is 0,
      that is, the page was updated by MariaDB Server 10.3. Earlier versions
      would always write the TRX_UNDO_PAGE_TYPE as 1 or 2.
      
      trx_undo_header_create(): Zero out the TRX_UNDO_TRX_NO field.
      Strictly speaking, this will change the semantics of the
      MLOG_UNDO_HDR_CREATE record, but it should not do any harm to
      overwrite a potentially garbage field with zeroes.
      
      Note: This fix will only help future upgrades straight from
      MariaDB Server 10.2 or MySQL 5.6 or earlier. If such an upgrade has
      already been made, then an earlier server startup could have
      fast-forwarded the transaction ID sequence to a large value.
      If this large value cannot be represented in 48 bits (the size of
      the DB_TRX_ID column in clustered index records), then various
      strange things can happen.
      0635088d
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 535bef86
      Marko Mäkelä authored
      535bef86
  8. 25 Feb, 2022 1 commit
    • Brandon Nesterenko's avatar
      MDEV-27850: MTR tests can hang due to DEBUG_SYNC race condition · 905baa64
      Brandon Nesterenko authored
      DEBUG_SYNC signals can get lost in certain tests due to later
      DEBUG_SYNC commands overwriting them. This patch addresses
      these issues in three tests: main.query_cache_debug,
      main.partition_debug_sync, and
      rpl.rpl_dump_request_retry_warning.
      
      Additionally, main.partition_debug_sync needed changes to the
      result file (the others did not). The synchronization happened
      between two commands, one based on ALTER, the other on DROP.
      A new thread/connection was needed to synchronize the DEBUG_SYNC
      actions between these commands, thereby changing the result file.
      Additional comments were added for clarification.
      
      Reviewed By:
      ============
      Andrei Elkin <andrei.elkin@mariadb.com>
      905baa64