1. 22 Jan, 2024 1 commit
    • Brandon Nesterenko's avatar
      MDEV-7850: Extend GTID Binlog Events with Thread Id · c37b2087
      Brandon Nesterenko authored
      This patch augments Gtid_log_event with the user thread-id.
      In particular that compensates for the loss of this info in
      Rows_log_events.
      
      Gtid_log_event::thread_id gets visible in mysqlbinlog output like
      
        #231025 16:21:45 server id 1  end_log_pos 537 CRC32 0x1cf1d963  GTID 0-1-2 ddl thread_id=10
      
      as 64 bit unsigned integer.
      
      While the size of Gtid event has grown by 8-9 bytes
      replication from OLD <-> NEW is not affected by it.
      
      This work was started by the late Sujatha Sivakumar.
      Brandon Nesterenko took it over, reviewed initial patches and extended
      the work.
      
      Reviewed-by: <andrei.elkin@mariadb.com>
      c37b2087
  2. 18 Jan, 2024 1 commit
    • Libing Song's avatar
      MDEV-32894 mysqlbinlog flashback support binlog_row_image FULL_NODUP mode · 8bf9f218
      Libing Song authored
      Summary
      =======
      With FULL_NODUP mode, before image inclues all columns and after
      image inclues only the changed columns. flashback will swap the
      value of changed columns from after image to before image.
      For example:
        BI: c1, c2, c3_old, c4_old
        AI: c3_new, c4_new
      flashback will reconstruct the before and after images to
        BI: c1, c2, c3_new, c4_new
        AI: c3_old, c4_old
      
      Implementation
      ==============
      When parsing the before and after image, position and length of
      the fields are collected into ai_fields and bi_fields, if it is an
      Update_rows_event and the after image doesn't includes all columns.
      
      The changed fields are swapped between bi_fields and ai_fields.
      Then it recreates the before image and after image by using
      bi_fields and ai_fields. nullbit will be set to 1 if the
      field is NULL, otherwise nullbit will be 0.
      
      It also optimized flashback a little bit.
      - calc_row_event_length is used instead of print_verbose_one_row
      - swap_buff1 and swap_buff2 are removed.
      8bf9f218
  3. 17 Jan, 2024 1 commit
  4. 12 Jan, 2024 1 commit
    • Libing Song's avatar
      MDEV-33049 Assertion `marked_for_write_or_computed()' failed in bool · be6d48fd
      Libing Song authored
                 Field_new_decimal::store_value(const my_decimal*, int*)
      
      Analysis
      ========
      When rpl applier is unpacking a before row image, Field::reset() will be
      called before setting a field to null if null bit of the field is set in
      the row image. For Field_new_decimal::reset(), it calls
      Field_new_decimal::store_value() to reset the value. store_value() asserts
      that the field is in the write_set bitmap since it thinks the field is
      updating.
      
      But that is not true for the row image generated in FULL_NODUP
      mode. In the mode, the before image includes all fields and the after
      image includes only updated fields.
      
      Fix
      ===
      In the case unpacking binlog row images, the assertion is meaningless.
      So the unpacking field is marked in write_set temporarily to avoid the
      assertion failure.
      be6d48fd
  5. 10 Jan, 2024 10 commits
    • Marko Mäkelä's avatar
      Merge 11.3 into 11.4 · d136169e
      Marko Mäkelä authored
      d136169e
    • Marko Mäkelä's avatar
      Merge 11.2 into 11.3 · af4f9dae
      Marko Mäkelä authored
      af4f9dae
    • Marko Mäkelä's avatar
      Merge 11.1 into 11.2 · e4cb1e32
      Marko Mäkelä authored
      e4cb1e32
    • Marko Mäkelä's avatar
      Merge 11.0 into 11.1 · c3a546e9
      Marko Mäkelä authored
      c3a546e9
    • Marko Mäkelä's avatar
      Merge 10.11 into 11.0 · c2da55ac
      Marko Mäkelä authored
      c2da55ac
    • Marko Mäkelä's avatar
      MDEV-26195 fixup: Remove page_no_t · 338ed5c4
      Marko Mäkelä authored
      338ed5c4
    • Marko Mäkelä's avatar
      Merge 10.6 into 10.11 · 1eb11da3
      Marko Mäkelä authored
      1eb11da3
    • Marko Mäkelä's avatar
      MDEV-33112 innodb_undo_log_truncate=ON is blocking page write · 3613fb2a
      Marko Mäkelä authored
      When innodb_undo_log_truncate=ON causes an InnoDB undo tablespace
      to be truncated, we must guarantee that the undo tablespace will
      be rebuilt atomically: After mtr_t::commit_shrink() has durably
      written the mini-transaction that rebuilds the undo tablespace,
      we must not write any old pages to the tablespace.
      
      To guarantee this, in trx_purge_truncate_history() we used to
      traverse the entire buf_pool.flush_list in order to acquire
      exclusive latches on all pages for the undo tablespace that
      reside in the buffer pool, so that those pages cannot be written
      and will be evicted during mtr_t::commit_shrink(). But, this
      traversal may interfere with the page writing activity of
      buf_flush_page_cleaner(). It would be better to lazily discard
      the old pages of the truncated undo tablespace.
      
      fil_space_t::is_being_truncated, fil_space_t::clear_stopping(): Remove.
      
      fil_space_t::create_lsn: A new field, identifying the LSN of the
      latest rebuild of a tablespace.
      
      buf_page_t::flush(), buf_flush_try_neighbors(): Evict pages whose
      FIL_PAGE_LSN is below fil_space_t::create_lsn.
      
      mtr_t::commit_shrink(): Update fil_space_t::create_lsn and
      fil_space_t::size right before the log is durably written and the
      tablespace file is being truncated.
      
      fsp_page_create(), trx_purge_truncate_history(): Simplify the logic.
      
      Reviewed by: Thirunarayanan Balathandayuthapani, Vladislav Lesin
      Performance tested by: Axel Schwenke
      Correctness tested by: Matthias Leich
      3613fb2a
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      MDEV-33137: Assertion end_lsn == page_lsn failed in recv_recover_page · 4cbf75dd
      Marko Mäkelä authored
      trx_purge_free_segment(), trx_purge_truncate_rseg_history():
      Do not claim that the blocks will be modified in the mini-transaction,
      because that will not always be the case. Whenever there is a
      modification, mtr_t::set_modified() will flag it.
      
      The debug assertion that failed in recovery is checking that all
      changes to data pages are covered by log records. Due to these
      incorrect calls, we would unnecessarily write unmodified data pages,
      which is something that commit 05fa4558
      aims to avoid.
      
      The incorrect calls had originally been added in
      commit de31ca6a (MDEV-32820) and
      commit 86767bcc (MDEV-29593).
      
      Reviewed by: Vladislav Lesin
      Tested by: Elena Stepanova
      4cbf75dd
  6. 09 Jan, 2024 7 commits
  7. 08 Jan, 2024 4 commits
  8. 05 Jan, 2024 5 commits
  9. 03 Jan, 2024 8 commits
    • Marko Mäkelä's avatar
      Merge 10.11 into 11.0 · 5be8b137
      Marko Mäkelä authored
      5be8b137
    • Marko Mäkelä's avatar
      Merge 10.6 into 10.11 · bdf65893
      Marko Mäkelä authored
      bdf65893
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · 8bd5a3de
      Marko Mäkelä authored
      8bd5a3de
    • Marko Mäkelä's avatar
      MDEV-33156 Crash on innodb_buf_flush_list_now=ON and innodb_force_recovery=6 · cc5c0eda
      Marko Mäkelä authored
      srv_start(): Move a read only mode startup tweak from
      innodb_init_params() to the correct location. Also if
      innodb_force_recovery=6 we will disable the doublewrite buffer,
      because InnoDB must run in read-only mode to prevent further corruption.
      
      This change only affects debug checks. Whenever srv_read_only_mode holds,
      the buf_pool.flush_list will be empty, that is, there will be no writes
      of persistent InnoDB data pages.
      
      Reviewed by: Thirunarayanan Balathandayuthapani
      cc5c0eda
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · 3a3a4f04
      Marko Mäkelä authored
      3a3a4f04
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-33098 The test innodb.doublewrite_debug occasionally fails to start up InnoDB · 77b8bedf
      Thirunarayanan Balathandayuthapani authored
      - innodb.doublewrite_debug should avoid the checkpoint
      before killing the server. So used debug sync and
      innodb_flush_sync to avoid the checkpoint completely.
      Test case allowed to skip on MSAN builder due to extra
      checkpoint.
      77b8bedf
    • Marko Mäkelä's avatar
      MDEV-33157 WSREP: Fix function pointer mismatch · 96130b18
      Marko Mäkelä authored
      wsrep_plugin_init(), wsrep_plugin_deinit(): Remove these dummy functions
      in order to fix an error that would be flagged by cmake -DWITH_UBSAN=ON
      when using clang.
      
      wsrep_show_ready(), wsrep_show_bf_aborts(): Correct the signature.
      96130b18
    • Igor Babaev's avatar
      MDEV-29362 Crash with query using constant subquery as left part of IN subquery · 832e96de
      Igor Babaev authored
      If a query has a HAVING clause that contains a predicate with a constant
      IN subquery whose lef part in its turn is a subquery and the predicate is
      subject to pushdown from HAVING to WHERE then execution of the query could
      cause a crash of the server.
      
      The cause of the problem was the missing implementation of the walk()
      method for the class Item_in_optimizer. As a result in some cases the left
      operand of the Item_in_optimizer condition could be traversed twice by
      the walk procedure. For many call-back functions used as an argument of
      this procedure it does not matter. Yet it matters for the call-back
      function cleanup_excluding_immutables_processor() used in pushdown of
      predicates from HAVING to WHERE. If the processed item is marked with
      the IMMUTABLE_FL flag then the processor just removes this flag, otherwise
      it performs cleanup of the item making it unfixed. If an item is marked
      with an the IMMUTABLE_FL and it traversed with this processor twice then
      it becomes unfixed after the second traversal though the flag indicates
      that the item should not be cleaned up.
      
      Approved by Oleksandr Byelkin <sanja@mariadb.com>
      832e96de
  10. 02 Jan, 2024 1 commit
  11. 27 Dec, 2023 1 commit
    • Alexander Barkov's avatar
      MDEV-33019 The database part is not case sensitive in SP names · 9695974e
      Alexander Barkov authored
      Problem:
      
      sp_cache erroneously looked up fully qualified SP names (e.g. `DB`.`SP`),
      in case insensitive style. It was wrong, because only the "name"
      part is always case insensitive, while the "db" part should be compared
      according to lower_case_table_names (case sensitively for 0,
      case insensitively for 1 and 2).
      
      Fix:
      
      Adding a "casedn_name" parameter make_qname() to tell
      if the name part should be lower cased:
        `DB1`.`SP` -> "DB1.SP"  (when casedn_name=false)
        `DB1`.`SP` -> "DB1.sp"  (when casedn_name=true)
      and using make_qname() with casedn_name=true when creating
      sp_cache hash lookup keys.
      
      Details:
      
      As a result, it now works as follows:
      - sp_head::m_db is converted to lower case if lower_case_table_names>0
        during the sp_name initialization phase. So when make_qname() is called,
        sp_head::m_db is already normalized. There are no changes in here.
      
      - The initialization phase of sp_head when creating sp_head::m_qname
        now calls make_qname() with casedn_name=true,
        so sp_head::m_name gets written to sp_head::m_qname in lower case.
      
      - sp_cache_lookup() now also calls make_qname() with casedn_name=true,
        so sp_head::m_name gets written to the temporary lookup key in lower case.
      
      - sp_cache::m_hashtable now uses case sensitive comparison
      9695974e