1. 12 Jun, 2019 5 commits
  2. 10 Jun, 2019 1 commit
    • Marko Mäkelä's avatar
      MDEV-19725 Incorrect error handling in ALTER TABLE · cbac8f93
      Marko Mäkelä authored
      Some I/O functions and macros that are declared in os0file.h used to
      return a Boolean status code (nonzero on success). In MySQL 5.7, they
      were changed to return dberr_t instead. Alas, in MariaDB Server 10.2,
      some uses of functions were not adjusted to the changed return value.
      
      Until MDEV-19231, the valid values of dberr_t were always nonzero.
      This means that some code that was incorrectly checking for a zero
      return value from the functions would never detect a failure.
      
      After MDEV-19231, some tests for ALTER ONLINE TABLE would fail with
      cmake -DPLUGIN_PERFSCHEMA=NO. It turned out that the wrappers
      pfs_os_file_read_no_error_handling_int_fd_func() and
      pfs_os_file_write_int_fd_func() were wrongly returning
      bool instead of dberr_t. Also the callers of these functions were
      wrongly expecting bool (nonzero on success) instead of dberr_t.
      
      This mistake had been made when the addition of these functions was
      merged from MySQL 5.6.36 and 5.7.18 into MariaDB Server 10.2.7.
      
      This fix also reverts commit 40becbc3
      which attempted to work around the problem.
      cbac8f93
  3. 07 Jun, 2019 2 commits
  4. 06 Jun, 2019 5 commits
  5. 05 Jun, 2019 3 commits
  6. 04 Jun, 2019 1 commit
    • Varun Gupta's avatar
      MDEV-18015: Assertion `global_status_var.global_memory_used == 0' failed when... · 7906bee6
      Varun Gupta authored
      MDEV-18015: Assertion `global_status_var.global_memory_used == 0' failed when using UDF , window functions and views
      
      Adding destructor for Group_bound_tracker to free Cached_item_str.
      The Cached_item for window functions are allocated on THD:mem_root
      but the Cached_item_str has value of type string which is allocated on
      the heap, so we need to call free() for it
      7906bee6
  7. 03 Jun, 2019 9 commits
  8. 31 May, 2019 3 commits
    • Alexander Barkov's avatar
      5a19908b
    • Vlad Lesin's avatar
      MDEV-18207: ASAN heap-use-after-free in _ma_get_status upon concurrent operations with sequence · c9b49a4b
      Vlad Lesin authored
      The issue is that two MARIA_HA instances shares the same MARIA_STATUS_INFO
      object during UNION execution, so the second MARIA_HA instance state pointer
      MARIA_HA::state points to the MARIA_HA::state_save of the first MARIA instance.
      
      This happens in
      thr_multi_lock(...) {
      ...
      	for (first_lock=data, pos= data+1 ; pos < end ; pos++)
      	{
      ...
      		if (pos[0]->lock == pos[-1]->lock && pos[0]->lock->copy_status)
      			(pos[0]->lock->copy_status)((*pos)->status_param,
      																	(*first_lock)->status_param);
      ...
      	}
      ...
      }
      
      Usually the state is restored from ha_maria::external_lock(...):
      
      \#0  _ma_update_status (param=0x6290000e6270) at ./storage/maria/ma_state.c:309
      \#1  0x00005555577ccb15 in _ma_update_status_with_lock (info=0x6290000e6270) at ./storage/maria/ma_state.c:361
      \#2  0x00005555577c7dcc in maria_lock_database (info=0x6290000e6270, lock_type=2) at ./storage/maria/ma_locking.c:66
      \#3  0x0000555557802ccd in ha_maria::external_lock (this=0x61d0001b1308, thd=0x62a000048270, lock_type=2) at ./storage/maria/ha_maria.cc:2727
      
      But _ma_update_status() does not take into account the case when
      MARIA_HA::status points to the MARIA_HA::state_save of the other MARIA_HA
      instance.
      
      The fix is to restore MARIA_HA::state in ha_maria::external_lock() after
      maria_lock_database() call for transactional tables.
      c9b49a4b
    • Marko Mäkelä's avatar
      Define page_id_t in buf0types.h · 9d142a89
      Marko Mäkelä authored
      9d142a89
  9. 30 May, 2019 4 commits
  10. 29 May, 2019 6 commits
    • Sujatha's avatar
      MDEV-11094: Blackhole table updates on slave fail when row annotation is enabled · a47464d1
      Sujatha authored
      Post push fix.
      
      Simplified the earlier fixes.
      a47464d1
    • Marko Mäkelä's avatar
      1d0c2741
    • Sujatha's avatar
      MDEV-11094: Blackhole table updates on slave fail when row annotation is enabled · b3473961
      Sujatha authored
      Problem:
      =======
      rpl_blackhole.test fails when executed with following options
      mysqld=--binlog_annotate_row_events=1, mysqld=--replicate_annotate_row_events=1
      
      Test output:
      ------------
      worker[1] Using MTR_BUILD_THREAD 300, with reserved ports 16000..16019
      rpl.rpl_blackhole_bug 'mix'              [ pass ]    791
      rpl.rpl_blackhole_bug 'row'              [ fail ]
      Replicate_Wild_Ignore_Table
      Last_Errno	1032
      Last_Error	Could not execute Update_rows_v1 event on table test.t1; Can't find
      record in 't1', Error_code: 1032; handler error HA_ERR_END_OF_FILE; the event's
      master log master-bin.000001, end_log_pos 1510
      
      Analysis:
      =========
      Enabling "replicate_annotate_row_events" on slave, Tells the slave to write
      annotate rows events received from the master to its own binary log. The
      received annotate events are applied after the Gtid event as shown below.
      thd->query() will be set to the actual query received from the master, through
      annotate event. Annotate_rows event should not be deleted after the event is
      applied as the thd->query will be used to generate new Annotate_rows event
      during applying the subsequent Rows events. After the last Rows event has been
      applied, the saved Annotate_rows event (if any) will be deleted.
      
      In balckhole engine all the DML operations are noops as they donot store any
      data. They simply return success without doing any operation. But the existing
      strictly expects thd->query() to be 'NULL' to identify that row based
      replication is in use. This assumption will fail when row annotations are
      enabled as the query is not 'NULL'. Hence various row based operations like
      'update', 'delete', 'index lookup' will fail when row annotations are enabled.
      
      Fix:
      ===
      Extend the row based replication check to include row annotations as well.
      i.e Either the thd->query() is NULL or thd->query() points to query and row
      annotations are in use.
      b3473961
    • Marko Mäkelä's avatar
      MDEV-19541: Avoid infinite loop of reading a corrupted page · 6eefeb6f
      Marko Mäkelä authored
      row_search_mvcc(): Duplicate the logic of btr_pcur_move_to_next()
      so that an infinite loop can be avoided when advancing to the next
      page fails due to a corrupted page.
      6eefeb6f
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      MDEV-19541: Add a forgotten test case · 642ddc31
      Marko Mäkelä authored
      Also, --skip-innodb-buffer-pool-load-at-startup to avoid a crash
      in buf_load() due to loading pages that we are corrupting intentionally.
      642ddc31
  11. 28 May, 2019 1 commit
    • Marko Mäkelä's avatar
      MDEV-19587 innodb_force_recovery=5 crash on DROP SCHEMA · 1ca75ae1
      Marko Mäkelä authored
      At higher levels of innodb_force_recovery, the InnoDB transaction
      subsystem will not be set up at all.
      
      At slightly lower levels, recovered transactions will not be rolled back,
      and DDL operations could hang due to locks being held at all.
      
      Let us consistently refuse all writes if the predicate
      high_level_read_only holds. We failed to refuse DROP TABLE
      and DROP DATABASE. (Refusing DROP TABLE is a partial backport
      from MDEV-19570 in the 10.5 branch.)
      1ca75ae1