1. 12 Jan, 2018 2 commits
    • Marko Mäkelä's avatar
      MDEV-14935 Remove bogus conditions related to not redo-logging PAGE_MAX_TRX_ID changes · 3e6fcb6a
      Marko Mäkelä authored
      InnoDB originally skipped the redo logging of PAGE_MAX_TRX_ID changes
      until I enabled it in commit e76b873f
      that was part of MySQL 5.5.5 already.
      
      Later, when a more complete history of the InnoDB Plugin for MySQL 5.1
      (aka branches/zip in the InnoDB subversion repository) and of the
      planned-to-be closed-source branches/innodb+ that became the basis of
      InnoDB in MySQL 5.5 was pushed to the MySQL source repository, the
      change was part of commit 509e761f:
      
       ------------------------------------------------------------------------
       r5038 | marko | 2009-05-19 22:59:07 +0300 (Tue, 19 May 2009) | 30 lines
      
       branches/zip: Write PAGE_MAX_TRX_ID to the redo log. Otherwise,
       transactions that are started before the rollback of incomplete
       transactions has finished may have an inconsistent view of the
       secondary indexes.
      
       dict_index_is_sec_or_ibuf(): Auxiliary function for controlling
       updates and checks of PAGE_MAX_TRX_ID: check whether an index is a
       secondary index or the insert buffer tree.
      
       page_set_max_trx_id(), page_update_max_trx_id(),
       lock_rec_insert_check_and_lock(),
       lock_sec_rec_modify_check_and_lock(), btr_cur_ins_lock_and_undo(),
       btr_cur_upd_lock_and_undo(): Add the parameter mtr.
      
       page_set_max_trx_id(): Allow mtr to be NULL.  When mtr==NULL, do not
       attempt to write to the redo log.  This only occurs when creating a
       page or reorganizing a compressed page.  In these cases, the
       PAGE_MAX_TRX_ID will be set correctly during the application of redo
       log records, even though there is no explicit log record about it.
      
       btr_discard_only_page_on_level(): Preserve PAGE_MAX_TRX_ID.  This
       function should be unreachable, though.
      
       btr_cur_pessimistic_update(): Update PAGE_MAX_TRX_ID.
      
       Add some assertions for checking that PAGE_MAX_TRX_ID is set on all
       secondary index leaf pages.
      
       rb://115 tested by Michael, fixes Issue #211
       ------------------------------------------------------------------------
      
      After this fix, some bogus references to recv_recovery_is_on()
      remained. Also, some references could be replaced with
      references to index->is_dummy to prepare us for MDEV-14481
      (background redo log apply).
      3e6fcb6a
    • Otto Kekäläinen's avatar
      Minor spelling fixes in code comments, docs and output · c9c28bef
      Otto Kekäläinen authored
      This commit does not touch any variable names or any other actual code,
      and thus should not in any way affect how the code works.
      c9c28bef
  2. 11 Jan, 2018 13 commits
    • Marko Mäkelä's avatar
      After-merge fix to innodb.log_corruption · 21239bb0
      Marko Mäkelä authored
      21239bb0
    • Marko Mäkelä's avatar
      Merge bb-10.2-ext into 10.3 · 6dd302d1
      Marko Mäkelä authored
      6dd302d1
    • Marko Mäkelä's avatar
      Merge 10.2 into bb-10.2-ext · cca611d1
      Marko Mäkelä authored
      cca611d1
    • Monty's avatar
      Removed duplicated copyright message · bf771911
      Monty authored
      bf771911
    • Marko Mäkelä's avatar
      MDEV-14824 Assertion `!trx_is_started(trx)' failed in innobase_start_trx_and_assign_read_view · 773c3ceb
      Marko Mäkelä authored
      In CREATE SEQUENCE or CREATE TEMPORARY SEQUENCE, we should not start
      an InnoDB transaction for inserting the sequence status record into
      the underlying no-rollback table. Because we did this, a debug assertion
      failure would fail in START TRANSACTION WITH CONSISTENT SNAPSHOT after
      CREATE TEMPORARY SEQUENCE was executed.
      
      row_ins_step(): Do not start the transaction. Let the caller do that.
      
      que_thr_step(): Start the transaction before calling row_ins_step().
      
      row_ins_clust_index_entry(): Skip locking and undo logging for no-rollback
      tables, even for temporary no-rollback tables.
      
      row_ins_index_entry(): Allow trx->id==0 for no-rollback tables.
      
      row_insert_for_mysql(): Do not start a transaction for no-rollback tables.
      773c3ceb
    • Marko Mäkelä's avatar
      Fix compilation warnings for libmariadb · 30ecd288
      Marko Mäkelä authored
      30ecd288
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · e9842de2
      Marko Mäkelä authored
      e9842de2
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      Merge 10.0 into 10.1 · c15b3d2d
      Marko Mäkelä authored
      c15b3d2d
    • Sergey Vojtovich's avatar
      MDEV-14638 - Replace trx_sys_t::rw_trx_set with LF_HASH · 0ca2ea1a
      Sergey Vojtovich authored
      trx reference counter was updated under mutex and read without any
      protection. This is both slow and unsafe. Use atomic operations for
      reference counter accesses.
      0ca2ea1a
    • Sergey Vojtovich's avatar
      MDEV-14638 - Replace trx_sys_t::rw_trx_set with LF_HASH · 380069c2
      Sergey Vojtovich authored
      trx_sys_t::rw_trx_set is implemented as std::set, which does a few quite
      expensive operations under trx_sys_t::mutex protection: e.g. malloc/free
      when adding/removing elements. Traversing b-tree is not that cheap either.
      
      This has negative scalability impact, which is especially visible when running
      oltp_update_index.lua benchmark on a ramdisk.
      
      To reduce trx_sys_t::mutex contention std::set is replaced with LF_HASH. None
      of LF_HASH operations require trx_sys_t::mutex (nor any other global mutex)
      protection.
      
      Another interesting issue observed with std::set is reproducible ~2% performance
      decline after benchmark is ran for ~60 seconds. With LF_HASH results are stable.
      
      All in all this patch optimises away one of three trx_sys->mutex locks per
      oltp_update_index.lua query. The other two critical sections became smaller.
      
      Relevant clean-ups:
      
      Replaced rw_trx_set iteration at startup with local set. The latter is needed
      because values inserted to rw_trx_list must be ordered by trx->id.
      
      Removed redundant conditions from trx_reference(): it is (and even was) never
      called with transactions that have trx->state == TRX_STATE_COMMITTED_IN_MEMORY.
      do_ref_count doesn't (and probably even didn't) make any sense: now it is called
      only when reference counter increment is actually requested.
      
      Moved condition out of mutex in trx_erase_lists().
      
      trx_rw_is_active(), trx_rw_is_active_low() and trx_get_rw_trx_by_id() were
      greatly simplified and replaced by appropriate trx_rw_hash_t methods.
      
      Compared to rw_trx_set, rw_trx_hash holds transactions only in PREPARED or
      ACTIVE states. Transactions in COMMITTED state were required to be found
      at InnoDB startup only. They are now looked up in the local set.
      
      Removed unused trx_assert_recovered().
      
      Removed unused innobase_get_trx() declaration.
      
      Removed rather semantically incorrect trx_sys_rw_trx_add().
      
      Moved information printout from trx_sys_init_at_db_start() to
      trx_lists_init_at_db_start().
      380069c2
    • Marko Mäkelä's avatar
      Merge 5.5 into 10.0 · 4c147954
      Marko Mäkelä authored
      4c147954
    • Marko Mäkelä's avatar
      MDEV-14916 InnoDB reports warning for "Purge reached the head of the history list" · bdcd7f79
      Marko Mäkelä authored
      The warning was originally added in
      commit c6766305
      (MySQL 4.1.12, 5.0.3) to trace claimed undo log corruption that
      was analyzed in https://lists.mysql.com/mysql/176250
      on November 9, 2004.
      
      Originally, the limit was 20,000 undo log headers or transactions,
      but in commit 9d6d1902
      in MySQL 5.5.11 it was increased to 2,000,000.
      
      The message can be triggered when the progress of purge is prevented
      by a long-running transaction (or just an idle transaction whose
      read view was started a long time ago), by running many transactions
      that UPDATE or DELETE some records, then starting another transaction
      with a read view, and finally by executing more than 2,000,000
      transactions that UPDATE or DELETE records in InnoDB tables. Finally,
      when the oldest long-running transaction is completed, purge would
      run up to the next-oldest transaction, and there would still be more
      than 2,000,000 transactions to purge.
      
      Because the message can be triggered when the database is obviously
      not corrupted, it should be removed. Heavy users of InnoDB should be
      monitoring the "History list length" in SHOW ENGINE INNODB STATUS;
      there is no need to spam the error log.
      bdcd7f79
  3. 10 Jan, 2018 9 commits
  4. 09 Jan, 2018 7 commits
  5. 08 Jan, 2018 9 commits