1. 02 May, 2017 2 commits
  2. 01 May, 2017 1 commit
    • Sergei Petrunia's avatar
      MyRocks: update to latest rocksdb · e13e1eea
      Sergei Petrunia authored
      - Update rocksdb submodule to revision
        d616ebea23fa88cb9c2c8588533526a566d9cfab
      - Normally this should be done by doing a merge from upstream
        MyRocks, but now we are just updating rocksdb, MyRocks merge will
        follow later.
      - Apply a part of 4f6f072f6c74513087004755508eb6d6c432c5c1
        use_direct_writes was renamed to use_direct_io_for_flush_and_compaction
      - Update build_rocksdb.cmake - RocksDB have moved files around
      e13e1eea
  3. 30 Apr, 2017 4 commits
  4. 29 Apr, 2017 1 commit
    • Igor Babaev's avatar
      Fixed the bug mdev-12563. · 7a29ca27
      Igor Babaev authored
      The bug happened when the specification of a recursive CTE had
      no recursive references at the top level of the specification.
      In this case the regular processing of derived table references
      of the select containing a non-recursive reference to this
      recursive CTE misses handling the specification unit.
      At the preparation stage any non-recursive reference to a
      recursive CTE must be handled after the preparation of the
      specification unit for this CTE. So we have to force this
      preparation when regular handling of derived tables does not
      do it.
      7a29ca27
  5. 28 Apr, 2017 3 commits
    • Marko Mäkelä's avatar
      MDEV-12602 InnoDB: Failing assertion: space->n_pending_ops == 0 · 4b24467f
      Marko Mäkelä authored
      This fixes a regression caused by MDEV-12428.
      When we introduced a variant of fil_space_acquire() that could
      increment space->n_pending_ops after space->stop_new_ops was set,
      the logic of fil_check_pending_operations() was broken.
      
      fil_space_t::n_pending_ios: A new field to track read or write
      access from the buffer pool routines immediately before a block
      write or after a block read in the file system.
      
      fil_space_acquire_for_io(), fil_space_release_for_io(): Similar
      to fil_space_acquire_silent() and fil_space_release(), but
      modify fil_space_t::n_pending_ios instead of fil_space_t::n_pending_ops.
      
      fil_space_free_low(): Wait for space->n_pending_ios to reach 0,
      to avoid accessing freed data in a concurrent thread. Future
      calls to fil_space_acquire_for_io() will not find this tablespace,
      because it will already have been detached from fil_system.
      
      Adjust a number of places accordingly, and remove some redundant
      tablespace lookups.
      
      FIXME: buf_page_check_corrupt() should take a tablespace from
      fil_space_acquire_for_io() as a parameter. This will be done
      in the 10.1 version of this patch and merged from there.
      That depends on MDEV-12253, which has not been merged from 10.1 yet.
      4b24467f
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · f740d23c
      Marko Mäkelä authored
      f740d23c
    • Sachin Setiya's avatar
      Fix binlog.flashback test. · e21c15a7
      Sachin Setiya authored
      e21c15a7
  6. 27 Apr, 2017 2 commits
    • Sachin Setiya's avatar
      Mdev-12017 Post Fix · eb55a9df
      Sachin Setiya authored
      Allow setting up binlog_format other then row for session scope for galera/
      flashback.
      
      Ref:- Mdev-7322
      eb55a9df
    • Marko Mäkelä's avatar
      Temporarily disable a failing test · 3167c912
      Marko Mäkelä authored
      On several buildbot machines, the test fails like this:
      
      CURRENT_TEST: wsrep.binlog_format
      mysqltest: At line 12: query 'SET binlog_format=STATEMENT' failed:
      1231: Variable 'binlog_format' can't be set to the value of 'STATEMENT'
      3167c912
  7. 26 Apr, 2017 27 commits
    • Marko Mäkelä's avatar
      Adapt a test from MySQL · 7fc93fd6
      Marko Mäkelä authored
      7fc93fd6
    • Aditya A's avatar
      Bug #23046302 COUNT(*) MUCH SLOWER ON 5.7 THAN 5.6 · 14fe6dd2
      Aditya A authored
      ANALYSIS
      
      This is regression caused due to worklog 6742 which
      implemented ha_innobase::records() which always
      uses clustered index to get the row count. Previously
      optimizer chose secondary index which was smaller in
      size of clustered index to scan for rows and resulted in
      a quicker scan.
      
      FIX
      
      After discussion it was decided to remove this feature in 5.7.
      
      [#rb14040 Approved by Kevin and Oystein ]
      14fe6dd2
    • Marko Mäkelä's avatar
      07f33115
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #25385590 DROP TABLE CRASHES IF INNODB_FORCE_RECOVERY > 4 · fca0698f
      Thirunarayanan Balathandayuthapani authored
      - Allow the server to start if innodb force recovery is set to 6
      even though change buffer is not empty
      Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
      fca0698f
    • Marko Mäkelä's avatar
      Adapt the test case for Oracle Bug#25385590 · 67e9c4cf
      Marko Mäkelä authored
      buf_chunk_not_freed(), logs_empty_and_mark_files_at_shutdown():
      Relax debug assertions when innodb_force_recovery=6
      implies innodb_read_only.
      67e9c4cf
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #25385590 DROP TABLE CRASHES IF INNODB_FORCE_RECOVERY > 4 · 7223ec4c
      Thirunarayanan Balathandayuthapani authored
      Problem:
      ========
       - Drop table assert if innodb_force_recovery is set to 5 or 6.
      For innodb_force_recovery 5 and 6, InnoDB doesn't scan the undo log
      and it makes the redo rollback segment as NULL. There is no way for
      transaction to write any undo log.
      
       - If innodb_force_recovery is set to 6 then InnoDB does not do the
      redo log roll-forward in connection with recovery. In this case,
      log_sys will be initalized only and it will not have latest
      checkpoint information. Checkpoint is done during shutdown even
      innodb_force_recovery is set to 6. So it leads to incorrect
      information update in checkpoint header.
      
      Solution:
      ========
      1) Allow drop table only if innodb_force_recovery < 5.
      2) Make innodb as read-only if innodb_force_recovery is set to 6.
      3) During shutdown, remove the checkpoint if innodb_force_recovery
      is set to 6.
      Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
      RB: 15075
      7223ec4c
    • Marko Mäkelä's avatar
      da0b2f09
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #24793413 LOG PARSING BUFFER OVERFLOW · 2ef1baa7
      Thirunarayanan Balathandayuthapani authored
      Problem:
      ========
      During checkpoint, we are writing all MLOG_FILE_NAME records in one mtr
      and parse buffer can't be processed till MLOG_MULTI_REC_END. Eventually parse
      buffer exceeds the RECV_PARSING_BUF_SIZE and eventually it overflows.
      
      Fix:
      ===
      1) Break the large mtr if it exceeds LOG_CHECKPOINT_FREE_PER_THREAD into multiple mtr during checkpoint.
      2) Move the parsing buffer if we are encountering only MLOG_FILE_NAME
      records. So that it will never exceed the RECV_PARSING_BUF_SIZE.
      Reviewed-by: default avatarDebarun Bannerjee <debarun.bannerjee@oracle.com>
      Reviewed-by: default avatarRahul M Malik <rahul.m.malik@oracle.com>
      RB: 14743
      2ef1baa7
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #25167032 CRASH WHEN ASSIGNING MY_ERRNO - MISSING MY_THREAD_INIT IN BACKGROUND THREAD · 88a84f49
      Thirunarayanan Balathandayuthapani authored
      Description:
      ===========
      Add my_thread_init() and my_thread_exit() for background threads which
      initializes and frees the st_my_thread_var structure.
      
      Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
      RB: 15003
      88a84f49
    • Marko Mäkelä's avatar
      e180f3c5
    • rahul malik's avatar
      BUG#25330449 ASSERT SIZE==SPACE->SIZE DURING BUF_READ_AHEAD_RANDOM · dbe4c4e3
      rahul malik authored
      Problem:
      
      During read head, wrong page size is used to calcuate the tablespace size.
      
      Fix:
      
      Use physical page size to calculate tablespace size
      
      Reveiwed-By: Satya Bodapati
      RB: 14993
      dbe4c4e3
    • Marko Mäkelä's avatar
      MariaDB adjustments for Oracle Bug#23070734 fix · 849af74a
      Marko Mäkelä authored
      Split the test case so that a server restart is not needed.
      Reduce the test cases and use a simpler mechanism for triggering
      and waiting for purge.
      
      fil_table_accessible(): Check if a table can be accessed without
      enjoying MDL protection.
      849af74a
    • Aditya A's avatar
      Bug #23070734 CONCURRENT TRUNCATE TABLES CAUSE STALLS · 62dca454
      Aditya A authored
      PROBLEM
      
      When truncating single tablespace tables, we need to scan the entire
      buffer pool to remove the pages of the table from the buffer pool.
      During this scan and removal dict_sys->mutex is being held ,causing
      stalls in other DDL operations.
      
      FIX
      
      Release the dict_sys->mutex during the scan and reacquire it after the
      scan. Make sure that purge thread doesn't purge the records of the table
      being truncated and background stats collection thread skips the updation
      of stats for the table being truncated.
      
      [#rb 14564 Approved by Jimmy and satya ]
      62dca454
    • Marko Mäkelä's avatar
      MDEV-11802 InnoDB purge does not always run when there is work to do · 13dcdb09
      Marko Mäkelä authored
      srv_sys_t::n_threads_active[]: Protect writes by both the mutex and
      by atomic memory access.
      
      srv_active_wake_master_thread_low(): Reliably wake up the master
      thread if there is work to do. The trick is to atomically read
      srv_sys->n_threads_active[].
      
      srv_wake_purge_thread_if_not_active(): Atomically read
      srv_sys->n_threads_active[] (and trx_sys->rseg_history_len),
      so that the purge should always be triggered when there is work to do.
      
      trx_commit_in_memory(): Invoke srv_wake_purge_thread_if_not_active()
      whenever a transaction is committed. Purge could have been prevented by
      the read view of the currently committing transaction, even if it is
      a read-only transaction.
      
      trx_purge_add_update_undo_to_history(): Do not wake up the purge.
      This is only called by trx_undo_update_cleanup(), as part of
      trx_write_serialisation_history(), which in turn is only called by
      trx_commit_low() which will always call trx_commit_in_memory().
      Thus, the added call in trx_commit_in_memory() will cover also
      this use case where a committing read-write transaction added
      some update_undo log to the purge queue.
      
      trx_rseg_mem_restore(): Atomically modify trx_sys->rseg_history_len.
      13dcdb09
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      Remove redundant initialization of global InnoDB variables · 6264e892
      Marko Mäkelä authored
      Also, remove the unused global variable srv_priority_boost.
      6264e892
    • Marko Mäkelä's avatar
      797db28d
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #23219499 CONCURRENT UPDATE DOESN'T APPLY IN VIRTUAL INDEX DURING TABLE REBUILD · 6b63e4ad
      Thirunarayanan Balathandayuthapani authored
      Problem:
      =======
      Concurrent update dml statement doesn't reflect in virtual index during
      inplace table rebuild. It results mismatch value in virutal index and
      clustered index. Deleting the table content tries to search the mismatch
      value in virtual index but it can't find the value. During log update
      apply phase, virtual information is being ignored while constructing
      the new entry.
      
      Solution:
      =========
      In row_log_update_apply phase, build the entry with virtual column
      information. So that it can reflect in newly constructed virtual index.
      
      Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
      RB: 14974
      6b63e4ad
    • Darshan M N's avatar
      BUG#25251082 DISABLING CERTAIN MACROS IN INNODB RESULTS IN COMPILATION ERRORS · 698e37d6
      Darshan M N authored
      Issue:
      ======
      Disabling macros such as UNIV_PFS_MUTEX/UNIV_PFS_RWLOCK/UNIV_PFS_THREAD
      which are defined in InnoDB throws errors during compilation.
      
      Fix:
      ====
      Fix all the compilation errors.
      
      RB: 14893
      Reviewed-by: default avatarJimmy Yang <Jimmy.Yang@oracle.com>
      Reviewed-by: default avatarSatya Bodapati <satya.bodapati@oracle.com>
      698e37d6
    • Darshan M N's avatar
      BUG#25053705 INVALID I/O ON TABLE AFTER TRUNCATE · 16ed1f9c
      Darshan M N authored
      Issue:
      ======
      The issue is that if a fts index is present in a table the space size is
      incorrectly calculated in the case of truncate which results in a invalid
      read.
      
      Fix:
      ====
      Have a different space size calculation in truncate if fts indexes are
      present.
      
      RB:14755
      Reviewed-by: default avatarShaohua Wang <shaohua.wang@oracle.com>
      16ed1f9c
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #24585978 INNODB: ASSERTION TOTAL_RECS > 0 FAILURE IN FILE DICT0STATS.CC · c2d9c0ce
      Thirunarayanan Balathandayuthapani authored
      Analysis:
      ========
       There was missing bracket for IF conditon in dict_stats_analyze_index_level()
      and it leads to wrong result.
      
      Fix:
      ====
       Fix the IF condition in dict_stats_analyze_index_level() so that it satisfied
      the if condtion only if level is zero.
      
      Reviewed-by : Jimmy Yang <jimmy.yang@oracle.com>
      c2d9c0ce
    • Thirunarayanan Balathandayuthapani's avatar
      Bug#25222337 FIELD NAME IS NULL IN NEWLY ADDED VIRTUAL INDEX FOR NEWLY ADDED VIRTUAL COLUMN · 35652ed6
      Thirunarayanan Balathandayuthapani authored
      Analysis:
      ========
      Field name comparison happens while filling the virtual columns
      affected by foreign constraint. But field name is NULL in virtual
      index for the newly added virtual column.
      
      Fix:
      ===
      Ignore the index if it has newly added virtual column. Foreign
      key affected virtual column information is filled during
      loading operation.
      Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
      RB: 14895
      35652ed6
    • Debarun Banerjee's avatar
      BUG#25126722 FOREIGN KEY CONSTRAINT NAME IS NULL IN INFORMATION_SCHEMA AFTER RESTART · 49edf2d4
      Debarun Banerjee authored
      Problem :
      ---------
      Information_Schema.referential_constraints (UNIQUE_CONSTRAINT_NAME)
      shows NULL for a foreign key constraint after restarting the server.
      If any dml or query (select/insert/update/delete) is done on
      referenced table, then the constraint name is correctly shown.
      
      Solution :
      ----------
      UNIQUE_CONSTRAINT_NAME column is the key name of the referenced table.
      In innodb, FK reference is stored as a list of columns in referenced
      table in INNODB_SYS_FOREIGN and INNODB_SYS_FOREIGN_COLS. The referenced
      column must have at least one index/key with the referenced column as
      prefix but the key name itself is not included in FK metadata. For this
      reason, the UNIQUE_CONSTRAINT_NAME is only filled up when the
      referenced table is actually loaded in innodb dictionary cache.
      
      The information_schema view calls handler::get_foreign_key_list() on
      foreign key table to read the FK metadata. The UNIQUE_CONSTRAINT_NAME
      information shows NULL based on whether the referenced table is
      already loaded or not.
      
      One way to fix this issue is to load the referenced table while reading
      the FK metadata information, if needed.
      Reviewed-by: default avatarSunny Bains <sunny.bains@oracle.com>
      
      RB: 14654
      49edf2d4
    • Allen Lai's avatar
      Bug#23044098 INSERT OF GIS DATA INTO RTREE HITS ASSERT IN RTR_CUR_RESTORE_POSITION_FUNC() · 07e88be5
      Allen Lai authored
      This bug is caused by missing page number field when store btree cursor.
      
      Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
      RB: 14617
      07e88be5
    • Debarun Banerjee's avatar
      BUG#25082593 FOREIGN KEY VALIDATION DOESN'T NEED TO ACQUIRE GAP LOCK IN READ COMMITTED · 4e41ac26
      Debarun Banerjee authored
      Problem :
      ---------
      This bug is filed from the base replication bug#25040331 where the
      slave thread times out while INSERT operation waits on GAP lock taken
      during Foreign Key validation.
      
      The primary reason for the lock wait is because the statements are
      getting replayed in different order. However, we also observed
      two things ...
      
      1. The slave thread could always use "Read Committed" isolation for
      row level replication.
      
      2. It is not necessary to have GAP locks in "READ Committed" isolation
      level in innodb.
      
      This bug is filed to address point(2) to avoid taking GAP locks during
      Foreign Key validation.
      
      Solution :
      ----------
      Innodb is primarily designed for "Repeatable Read" and the GAP lock
      behaviour is default. For "Read Committed" isolation, we have special
      handling in row_search_mvcc to avoid taking the GAP lock while
      scanning records.
      
      While looking for Foreign Key, the code is following the default
      behaviour taking GAP locks. The suggested fix is to avoid GAP
      locking during FK validation similar to normal search operation
      (row_search_mvcc) for "Read Committed" isolation level.
      Reviewed-by: default avatarSunny Bains <sunny.bains@oracle.com>
      
      RB: 14526
      4e41ac26
    • Debarun Banerjee's avatar
      BUG#25032066 PREPARED TRANSACTION SHOULD NOT BE ROLLED BACK BY HIGH PRIORITY TRANSACTION · bf5be323
      Debarun Banerjee authored
      Problem :
      ---------
      1. delete_all_rows() and rnd_init() are not returning error
      after async rollback in 5.7. This results in assert in
      innodb in next call.
      
      2. High priority transaction is rolling back prepared transaction.
      This is because TRX_FORCE_ROLLBACK_DISABLE is getting set only for
      first entry [TrxInInnoDB].
      
      Solution :
      ----------
      1. return DB_FORCED_ABORT error after rollback.
      2. check and disable rollback in TrxInInnodb::enter always.
      Reviewed-by: default avatarSunny Bains <sunny.bains@oracle.com>
      
      RB: 13777
      bf5be323
    • Knut Anders Hatlen's avatar
      Bug#25048573: STD::MAP INSTANTIATIONS CAUSE STATIC ASSERT FAILURES ON FREEBSD 11 · 9df04261
      Knut Anders Hatlen authored
      Problem: Some instantiations of std::map have discrepancies between
      the value_type of the map and the value_type of the map's allocator.
      On FreeBSD 11 this is detected by Clang, and an error is raised at
      compilation time.
      
      Fix: Specify the correct value_type for the allocators.
      
      Also fix an unused variable warning in storage/innobase/os/os0file.cc.
      9df04261