1. 13 Jan, 2018 5 commits
  2. 12 Jan, 2018 6 commits
  3. 11 Jan, 2018 11 commits
    • Andrei Elkin's avatar
      Added checking that row events ends with a proper end block · 3dc3ab1a
      Andrei Elkin authored
      Problems --------
      
      The slave io thread did not conduct integrity check
      for a group of row-based events. Specifically it tolerates missed
      terminal block event that must be flagged with STMT_END. Failure to
      react on its loss can confuse the applier thread in various ways.
      Another potential issue was that there were no check of impossible
      second in row Gtid-log-event while the slave io thread is receiving
      to be skipped events after reconnect.
      
      Fixes
      -----
      The slave io thread is made by this patch to track the rows event
      STMT_END status.
      Whenever at next event reading the IO thread finds out that a preceding
      Rows event did not actually had the flag, an
      explicit error is issued.
      
      Replication can be resumed after the source of failure is eliminated,
      see a provided test.
      
      Note that currently the row-based group integrity check excludes
      the compressed version 2 Rows events (which are not generated by MariaDB
      master).
      Its uncompressed counterpart is manually tested.
      
      The 2nd issue is covered to produce an error in case the io thread
      receives a successive Gtid_log_event while it is post-reconnect
      skipping.
      3dc3ab1a
    • Monty's avatar
      5fce14da
    • 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
    • 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
  4. 10 Jan, 2018 8 commits
  5. 09 Jan, 2018 4 commits
  6. 08 Jan, 2018 6 commits