1. 03 Apr, 2020 4 commits
  2. 02 Apr, 2020 7 commits
  3. 01 Apr, 2020 5 commits
    • Marko Mäkelä's avatar
      MDEV-22107 Restore accidentally orphaned MTR_MEMO_MODIFY · b212f1da
      Marko Mäkelä authored
      In MDEV-12353, the calls to mtr_t::memo_modify_page()
      were accidentally removed along with
      mlog_open_and_write_index() and its callers.
      
      Let us resurrect the function to enable better debug checks.
      
      mtr_t::flag_modified(): Renamed from mtr_t::set_modified()
      and made private.
      
      mtr_t::set_modified(): Take const buf_block_t& as a parameter.
      
      In several mtr_t member functions, replace const buf_page_t&
      parameters with const buf_block_t&, so that we can pass the
      parameter to set_modified().
      
      mtr_t::modify(): Add a MTR_MEMO_MODIFY entry for a block that
      is guaranteed to be modified in the mini-transaction.
      b212f1da
    • Marko Mäkelä's avatar
      MDEV-12353: Fix a warning in RelWithDebInfo build · 587f3e0d
      Marko Mäkelä authored
      page_zip_clear_rec(): Explicitly initialize len
      in non-debug builds to avoid a warning about possibly
      invalid memset() length.
      587f3e0d
    • Marko Mäkelä's avatar
      Fix GCC 9.3.0 -Wstrict-aliasing · 51a9dd67
      Marko Mäkelä authored
      copy_keys_from_share(): Use reinterpret_cast instead of
      manipulating a reference to a type-punned pointer.
      
      This cleans up after the cleanup
      commit 0515577d.
      51a9dd67
    • Marko Mäkelä's avatar
      MDEV-22103 INNODB_ENCRYPTION_NUM_KEY_REQUESTS is missing from INFORMATION_SCHEMA.GLOBAL_STATUS · abaeeffb
      Marko Mäkelä authored
      In commit a5584b13
      some scrubbing-related status variables were removed along with
      the background scrubbing code.
      The status variable INNODB_ENCRYPTION_NUM_KEY_REQUESTS
      was inadvertently removed as part of that.
      
      innodb_status_variables[]: Restore "encryption_num_key_requests".
      
      We introduce the test innodb.innodb_status_variables
      in order to catch similar regressions in the future.
      abaeeffb
    • Marko Mäkelä's avatar
      MDEV-22102 Assertion w==OPT failed in trx_undo_header_create() · a1077ab2
      Marko Mäkelä authored
      Because InnoDB is not freeing undo pages to the normal
      free-page management, old undo log pages can be reused. Due to that,
      it is possible (but unlikely) that the fields TRX_UNDO_NEEDS_PURGE
      and TRX_UNDO_LOG_START relative to the free offset that is stored at
      TRX_UNDO_PAGE_HDR + TRX_UNDO_PAGE_START already have the correct value.
      Hence, we must pass the mtr_t::OPT template parameter to silence the
      debug assertion.
      
      Other writes in trx_undo_header_create() that are using the default
      template parameter seem to be correct (the data fields should be
      guaranteed to change even in the event of reusing pages).
      a1077ab2
  4. 31 Mar, 2020 18 commits
  5. 30 Mar, 2020 6 commits
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · 37c14690
      Marko Mäkelä authored
      37c14690
    • Marko Mäkelä's avatar
      Cleanup recv_sys: Move things to members · aae3f921
      Marko Mäkelä authored
      recv_sys.recovery_on: Replaces recv_recovery_on.
      
      recv_sys_t::apply(): Replaces recv_apply_hashed_log_recs().
      
      recv_sys_var_init(): Remove.
      
      recv_sys_t::recover_low(): Attempt to initialize a page based
      on buffered redo log records.
      aae3f921
    • Marko Mäkelä's avatar
      MDEV-12353: Remove a trace of pre-MDEV-13564 crash-upgrade · a8b04c3e
      Marko Mäkelä authored
      In commit f8a9f906
      we removed support for crash-upgrade from older versions,
      but forgot to remove a check for recovering TRUNCATE TABLE
      if MariaDB 10.2.18 or 10.3.9 or earlier were killed and
      we are attempting to upgrade to MariaDB 10.5.2 or later.
      Already MariaDB 10.4 would refuse to recover such TRUNCATE
      operations.
      a8b04c3e
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · e2f1f88f
      Marko Mäkelä authored
      e2f1f88f
    • Marko Mäkelä's avatar
      MDEV-20590 Introduce a file format constraint to ALTER TABLE · b092d35f
      Marko Mäkelä authored
      If a table is altered using the MDEV-11369/MDEV-15562/MDEV-13134
      ALGORITHM=INSTANT, it can force the table to use a non-canonical
      format:
      
      * A hidden metadata record at the start of the clustered index
      is used to store each column's DEFAULT value. This makes it possible
      to add new columns that have default values without rebuilding the table.
      
      * Starting with MDEV-15562 in MariaDB Server 10.4, a BLOB in the
      hidden metadata record is used to store column mappings. This makes
      it possible to drop or reorder columns without rebuilding the table.
      This also makes it possible to add columns to any position or drop
      columns from any position in the table without rebuilding the table.
      
      If a column is dropped without rebuilding the table, old records
      will contain garbage in that column's former position, and new records
      will be written with NULL values, empty strings, or dummy values.
      
      This is generally not a problem. However, there may be cases where
      users may want to avoid putting a table into this format.
      For example, users may want to ensure that future UPDATE operations
      after an ADD COLUMN will be performed in-place, to reduce write
      amplification. (Instantly added columns are essentially always
      variable-length.) Users might also want to avoid bugs similar to
      MDEV-19916, or they may want to be able to export tables to
      older versions of the server.
      
      We will introduce the option innodb_instant_alter_column_allowed,
      with the following values:
      
      * never (0): Do not allow instant add/drop/reorder,
      to maintain format compatibility with MariaDB 10.x and MySQL 5.x.
      If the table (or partition) is not in the canonical format, then
      any ALTER TABLE (even one that does not involve instant column
      operations) will force a table rebuild.
      
      * add_last (1, default in 10.3): Store a hidden metadata record that
      allows columns to be appended to the table instantly (MDEV-11369).
      In 10.4 or later, if the table (or partition) is not in this format,
      then any ALTER TABLE (even one that does not involve column changes)
      will force a table rebuild.
      
      Starting with 10.4:
      
      * add_drop_reorder (2, default): Like 'add_last', but allow the
      metadata record to store a column map, to support instant
      add/drop/reorder of columns (MDEV-15562).
      b092d35f
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-21832 FORCE all partition to rebuild if any one of the · f8ec3ba0
      Thirunarayanan Balathandayuthapani authored
      		partition does rebuild
      
      - In ha_innobase::commit_inplace_alter_table() assumes that all partition
      should do the same kind of alter operations. During DDL, if one partition
      requires table rebuild and other partition doesn't need rebuild
      then all partition should be forced to rebuild.
      f8ec3ba0