1. 15 Aug, 2017 6 commits
    • Sergei Petrunia's avatar
      MDEV-13515: rocksdb.use_direct_reads_writes fails in buildbot with not found pattern · c354cb66
      Sergei Petrunia authored
      The test mis-used MTR's "restart the server if it crashed or exited"
      feature to try starting MyRocks plugin with invalid arguments.
      
      Changed the test to use the --default-storage-engine=myisam which
      allows the server to start when MyRocks fails to start.
      
      This removes the need to "start the server with the arguments which
      will caused it to fail to start", and so removes the race conditions
      with MTR server restart code and  mysqld.*.expect file.
      c354cb66
    • Marko Mäkelä's avatar
      MDEV-13331 FK DELETE CASCADE does not honor innodb_lock_wait_timeout · 5d1c0d00
      Marko Mäkelä authored
      row_ins_check_foreign_constraint(): On timeout,
      return DB_LOCK_WAIT_TIMEOUT instead of DB_LOCK_WAIT,
      so that the lock wait will be properly terminated.
      Also, replace some redundant assignments.
      
      It looks like this bug was introduced in MySQL 5.7.8 by:
      
          commit a97f6b91227c7e0fc3151cfe5421891e79c12d19
          Author: Annamalai Gurusami <annamalai.gurusami@oracle.com>
          Date:   Tue Jun 9 16:02:31 2015 +0530
      
              Bug #20953265 INNODB: FAILING ASSERTION: RESULT != FTS_INVALID
      5d1c0d00
    • Marko Mäkelä's avatar
      MDEV-13498 DELETE with CASCADE constraints takes long time / MDEV-13246 · 2f342c45
      Marko Mäkelä authored
      MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2
      by commit fec844ac
      which introduced some Galera-specific conditions that were being
      evaluated even if the write-set replication was not enabled.
      
      MDEV-13246 Stale rows despite ON DELETE CASCADE constraint
      is a correctness regression that was introduced by the same commit.
      
      Especially the subcondition
      	!(parent && que_node_get_type(parent) == QUE_NODE_UPDATE)
      which is equivalent to
      	!parent || que_node_get_type(parent) != QUE_NODE_UPDATE
      makes little sense. If parent==NULL, the evaluation would proceed to the
      std::find() expression, which would dereference parent. Because no SIGSEGV
      was observed related to this, we can conclude that parent!=NULL always
      holds. But then, the condition would be equivalent to
      	que_node_get_type(parent) != QUE_NODE_UPDATE
      which would not make sense either, because the std::find() expression
      is actually assuming the opposite when casting parent to upd_node_t*.
      
      It looks like this condition never worked properly, or that
      it was never properly tested, or both.
      
      wsrep_must_process_fk(): Helper function to check if FOREIGN KEY
      constraints need to be processed. Only evaluate the costly std::find()
      expression when write-set replication is enabled.
      
      Also, rely on operator<<(std::ostream&, const id_name_t&) and
      operator<<(std::ostream&, const table_name_t&) for pretty-printing
      index and table names.
      
      row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition.
      This is applying part of "Galera MW-369 FK fixes"
      https://github.com/codership/mysql-wsrep/commit/f37b79c6dab101310a45a9e8cb23c0f98716da52
      that is described by the following part of the commit comment:
          additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has
          BF, essentially is applier or replaying
          This FK check would be needed only for populating parent row FK keys
          in write set, so no use for appliers
      2f342c45
    • Marko Mäkelä's avatar
      MDEV-13520 InnoDB attempts UPDATE with DB_TRX_ID=0 if innodb_force_recovery=3 · b4f6b678
      Marko Mäkelä authored
      trx_set_rw_mode(): Check the flag high_level_read_only instead
      of testing srv_force_recovery (innodb_force_recovery) directly.
      There is no need to prevent the creation of read-write transactions
      if innodb_force_recovery=3 is used. Yes, in that mode any recovered
      incomplete transactions will not be rolled back, but these transactions
      will continue to hold locks on the records that they have modified.
      If the new read-write transactions hit conflicts with already existing
      (possibly recovered) transactions, the lock wait timeout mechanism
      will work just fine.
      b4f6b678
    • Marko Mäkelä's avatar
      Fix a test result · a5e4365e
      Marko Mäkelä authored
      a5e4365e
    • Sergei Golubchik's avatar
      MDEV-13525 mtr and mysql-test-run symlinks are not installed anymore · c724fcd7
      Sergei Golubchik authored
      Install mtr and mysql-test-run symlinks in case of the out-of-source
      build. This was broken in c872b100
      c724fcd7
  2. 14 Aug, 2017 22 commits
  3. 11 Aug, 2017 2 commits
  4. 10 Aug, 2017 4 commits
    • Alexey Botchkov's avatar
      MDEV-12604 Comparison of JSON_EXTRACT result differs with Mysql. · 79d28533
      Alexey Botchkov authored
              JSON_EXTRACT behaves specifically in the comparison,
              so we have to implement specific method for that in
              Arg_comparator.
      79d28533
    • Marko Mäkelä's avatar
      Fix some GCC 7 warnings for InnoDB · bfffe571
      Marko Mäkelä authored
      buf_page_io_complete(): Do not test bpage for NULL, because
      it is declared (and always passed) as nonnull.
      
      buf_flush_batch(): Remove the constant local variable count=0.
      
      fil_ibd_load(): Use magic comment to suppress -Wimplicit-fallthrough.
      
      ut_stage_alter_t::inc(ulint): Disable references to an unused parameter.
      
      lock_queue_validate(), sync_array_find_thread(), rbt_check_ordering():
      Define only in debug builds.
      bfffe571
    • Oleksandr Byelkin's avatar
      MDEV-13439: Database permissions are not enough to run a subquery with GROUP BY within a view · cb2a57c2
      Oleksandr Byelkin authored
      The bug is result adding ability to have derived tables inside views.
      Fixed checks should be a switch between view/derived or select derived and information schema.
      cb2a57c2
    • Marko Mäkelä's avatar
      MDEV-13481 Merge new release of InnoDB MySQL 5.7.19 to 10.2 · bdab49d3
      Marko Mäkelä authored
      Only a relevant subset of the InnoDB changes was merged.
      In particular, two follow-up bug fixes for the bugs that
      were introduced in 5.7.18 but not MariaDB 10.2.7 were omitted.
      Because MariaDB 10.2.7 omitted the risky change
      
      Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE INDEX
      APPLIED BY UNCOMMITTED ROWS
      
      we do not need the follow-up fixes that were introduced in
      MySQL 5.6.37 and MySQL 5.7.19:
      
      Bug#25175249 ASSERTION: (TEMPL->IS_VIRTUAL && !FIELD) || ...
      Bug#25793677 INNODB: FAILING ASSERTION: CLUST_TEMPL_FOR_SEC || LEN
      bdab49d3
  5. 09 Aug, 2017 6 commits
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #24961167 CONCURRENT INSERT FAILS IF TABLE DOES REBUILD · 38be0beb
      Thirunarayanan Balathandayuthapani authored
      Analysis:
      =========
         During alter table rebuild, InnoDB fails to apply concurrent insert log.
      If the insert log record is present across the blocks then apply phase
      trying to access the next block without fetching it.
      
      Fix:
      ====
      During virtual column parsing, check whether the record is present
      across the blocks before accessing the virtual column information.
      Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
      RB: 16243
      38be0beb
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #24960450 CONCURRENT DELETE DOESN'T APPLY DURING TABLE REBUILD · 5721d5ba
      Thirunarayanan Balathandayuthapani authored
      Analysis:
      ========
      During alter table rebuild, InnoDB fails to apply concurrent delete log.
      Parsing and validation of merge record happens while applying the
      log operation on a table. Validation goes wrong for the virtual column.
      Validation assumes that virtual column information can't be the end
      of the merge record end.
      
      Fix:
      ====
      Virtual column information in the merge record can be end of the merge
      record. Virtual column information is written at the end for
      row_log_table_delete().
      
      Reviewed-by: Satya Bodapati<satya.bodapati@oracle.com>
      RB: 16155
      5721d5ba
    • Marko Mäkelä's avatar
      Import a test case from MySQL 5.7.19 · ab2c3185
      Marko Mäkelä authored
      The test is for a bug that was introduced in MySQL 5.7.18
      but not MariaDB 10.2, because MariaDB did not merge the change
      that was considered incomplete and too risky for a GA release:
      
      Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE INDEX
      APPLIED BY UNCOMMITTED ROWS
      
      So, we are only merging the test changes from the bug fix in MySQL 5.7.19,
      not any code changes:
      
      commit 4f86aca37d551cc756d9187ec901f8c4a68a0543
      Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
      Date:   Wed Apr 26 11:10:41 2017 +0530
      
          Bug #25793677   INNODB: FAILING ASSERTION: CLUST_TEMPL_FOR_SEC || LEN
      ab2c3185
    • Marko Mäkelä's avatar
      Remove dead references to clust_templ_for_sec · f2eaac5d
      Marko Mäkelä authored
      MariaDB 10.2 never contained the Oracle change
      
      Bug#23481444 OPTIMISER CALL ROW_SEARCH_MVCC() AND READ THE
      INDEX APPLIED BY UNCOMMITTED ROWS
      
      because it was considered risky for a GA release and incomplete.
      Remove the references that were added when merging MySQL 5.6.36
      to MariaDB 10.0.31, 10.1.24, and 10.2.7.
      f2eaac5d
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #25357789 INNODB: LATCH ORDER VIOLATION DURING TRUNCATE TABLE IF INNODB_SYNC_DEBUG ENABLED · 9d57468d
      Thirunarayanan Balathandayuthapani authored
      Analysis:
      ========
      
      (1) During TRUNCATE of file_per_table tablespace, dict_operation_lock is
      released before eviction of dirty pages of a tablespace from the buffer
      pool. After eviction, we try to re-acquire
      dict_operation_lock (higher level latch) but we already hold lower
      level latch (index->lock). This causes latch order violation
      
      (2) Deadlock issue is present if child table is being truncated and it
      holds index lock. At the same time, cascade dml happens and it took
      dict_operation_lock and waiting for index lock.
      
      Fix:
      ====
      1) Release the indexes lock before releasing the dict operation lock.
      
      2) Ignore the cascading dml operation on the parent table, for the
      cascading foreign key, if the child table is truncated or if it is
      in the process of being truncated.
      Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
      Reviewed-by: default avatarKevin Lewis <kevin.lewis@oracle.com>
      RB: 16122
      9d57468d
    • Darshan M N's avatar
      BUG#25365223 ERRORLOG UPDATED WITH NOTES INFORMATION WHEN A REF FKEY ISN'T FOUND IN GRSETUP · bf8054b0
      Darshan M N authored
      Issue
      ====
      The issue is that the info message that InnoDB prints when a table
      is created with a reference which doesn't exist fills up the log as
      it's printed for every insert when foreign_key_checks is disabled.
      
      Fix
      ===
      The fix is to display the message only if foreign_key_checks is
      enabled.
      Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
      bf8054b0