1. 14 May, 2019 11 commits
    • Marko Mäkelä's avatar
      MDEV-19445: After-merge fix · 49373397
      Marko Mäkelä authored
      Pass a correct string pointer to RETURN_IF_INNODB_NOT_STARTED.
      This was caught on Windows. The error was introduced in the
      merge commit 874f8f30.
      49373397
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 73e03852
      Marko Mäkelä authored
      73e03852
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 874f8f30
      Marko Mäkelä authored
      874f8f30
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · be85d3e6
      Marko Mäkelä authored
      be85d3e6
    • Daniel Bartholomew's avatar
      bump the VERSION · c0bc9480
      Daniel Bartholomew authored
      c0bc9480
    • Marko Mäkelä's avatar
      MDEV-19449 Got error 168 for valid TRUNCATE (temporary) TABLE · 409e210e
      Marko Mäkelä authored
      Add the test case.
      
      The parent commit, which cherry-picked the MDEV-17167 fix from 10.3
      (commit bad2f156)
      fixed the bug.
      409e210e
    • Oleksandr Byelkin's avatar
      518cb2bb
    • Sergey Vojtovich's avatar
      MDEV-17167 - InnoDB: Failing assertion: table->get_ref_count() == 0 upon · 95fb88d5
      Sergey Vojtovich authored
                   truncating a temporary table
      
      TRUNCATE expects only one TABLE instance (which is used by TRUNCATE
      itself) to be open. However this requirement wasn't enforced after
      "MDEV-5535: Cannot reopen temporary table".
      
      Fixed by closing unused table instances before performing TRUNCATE.
      95fb88d5
    • Sujatha's avatar
      MDEV-19158: MariaDB 10.2.22 is writing duplicate entries into binary log · 43bbf88d
      Sujatha authored
      Problem:
      ========
      We have a Master/Master Setup on two servers, but are only writing to one of
      those servers (so it is essentially Master/Slave) We upgraded from 10.1.* to
      10.2.22 last week and starting with the upgrade, we are getting duplicate key
      errors on the slave. BINLOG=mixed.
      
      Analysis:
      =========
      This issue happens with LOCK TABLES and binlog_format=MIXED combination. When an
      UNSAFE statement is encountered in 'MIXED' mode, it is logged in the form of
      'ROW' format. For all the tables that are part of LOCK TABLES list their table maps
      are written into the binary log. For each table in the list a check is
      done to see if 'check_table_binlog_row_based_done' flag is set or not. If it is not set
      a check process is initiated to see if table qualifies for row based binary
      logging or not and 'check_table_binlog_row_based_done' is set. This flag will be
      cleared at the time of closing thread tables.
      
      But there can be special cases where the LOCK TABLES contains more number of
      tables but the unsafe query is actually using subset of tables from LOCK TABLES
      list.
      
      For example: LOCK TABLES locks t1,t2,t3 but the unsafe statement makes use of
      only two tables t1,t3. In this case the 'check_table_binlog_row_based_done' flag
      is enabled for table 't2' while writing table map, but 'close_thread_tables'
      function call will not reset this flag. Since the flag is not cleared for table
      't2' even a safe statement which used t2 will be logged in the form of row based
      format.
      
      This leads to an assert on debug builds and causes duplicate entries in release
      builds. In release builds a statement is logged in the form of both ROW and
      STATEMENT format. This causes the slave to fail with duplicate key error.
      
      Fix:
      ===
      During 'close_thread_tables' when LOCK TABLE modes are active "ha_reset" is done
      for all the tables which were part of current statement. As mentioned in the
      example 'ha_reset' is called for tables 't1' and 't3'. This will clear the
      'check_table_binlog_row_based_done' flag. At this point add a check for the rest
      of the tables to see if 'check_table_binlog_row_based_done' is enabled or not.
      If enabled clear the flag.
      43bbf88d
    • Sujatha's avatar
      Merge branch '10.1' into 10.2 · d0d663f3
      Sujatha authored
      d0d663f3
    • Sujatha's avatar
      MDEV-11095: rpl.rpl_row_mysqlbinlog test fails if row annotation enabled · 47637a3d
      Sujatha authored
      Problem:
      =======
      Whel rpl.rpl_row_mysqlbinlog test is executed as shown below it fails with
      result content mismatch.
      
      perl mtr rpl_row_mysqlbinlog --mysqld=--binlog-annotate-row-events=1
      
      Analysis:
      =========
      When row annotations are enabled the actual query is written into the binlog
      which helps users to understand the query, even when row based replication is
      enabled.
      
      For example: Simple insert in row based replication looks like shown below.
      
      #190402 16:31:27 server id 1  end_log_pos 526 	Annotate_rows:
      #Q> insert into t values (10)
      #190402 16:31:27 server id 1  end_log_pos 566 	Table_map: `test`.`t` mapped to number 19
      # at 566
      #190402 16:31:27 server id 1  end_log_pos 600 	Write_rows: table id 19 flags: STMT_END_F
      
      BINLOG '
      B0GjXBMBAAAAKAAAADYCAAAAABMAAAAAAAEABHRlc3QAAXQAAQMAAQ==
      B0GjXBcBAAAAIgAAAFgCAAAAABMAAAAAAAEAAf/+CgAAAA==
      '/*!*/;
      # at 600
      
      The test creates some binary log events and redirects them into a SQL file.
      Executes RESET MASTER and sources the SQL file back on clean master and verifies
      that the data is available. Please refer following steps.
      
      ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 > test.sql
      ../client/mysql -uroot -S./var/tmp/mysqld.1.sock -Dtest  < test.sql
      ../client/mysqlbinlog ./var/mysqld.1/data/master-bin.000001 -v > row.sql
      
      When the row based replication specific SQL file is sourced once again on master
      the newly generated binlog will treat the entire "BASE 64" encoded event as
      query and write it into the binary log.
      
      Output from 'row.sql':
      
      #Q> BINLOG '
      #Q> B0GjXBMBAAAAKAAAADYCAAAAABMAAAAAAAEABHRlc3QAAXQAAQMAAQ==
      #Q> B0GjXBcBAAAAIgAAAFgCAAAAABMAAAAAAAEAAf/+CgAAAA==
      #190402 16:31:27 server id 1  end_log_pos 657 	Table_map: `test`.`t` mapped to number 23
      # at 657
      #190402 16:31:27 server id 1  end_log_pos 691 	Write_rows: table id 23 flags: STMT_END_F
      
      BINLOG '
      B0GjXBMBAAAAKAAAAJECAAAAABcAAAAAAAEABHRlc3QAAXQAAQMAAQ==
      B0GjXBcBAAAAIgAAALMCAAAAABcAAAAAAAEAAQH+CgAAAA==
      ### INSERT INTO `test`.`t`
      ### SET
      ###   @1=10
      '/*!*/;
      # at 691
      
      
      This is expected behaviour as we cannot extract query from BASE 64 encoded
      input. This causes more number of binary logs to be generated when the test is
      executed with row annotations.
      
      The following lines from test assumes that only two binary logs will contain
      entire data.
      
       --echo --- Test 4 Second Remote test --
      ---exec $MYSQL_BINLOG --read-from-remote-server --user=root --host=127.0.0.1
      	--port=$MASTER_MYPORT master-bin.000001 > $MYSQLTEST_VARDIR/tmp/remote.sql
      ---exec $MYSQL_BINLOG --read-from-remote-server --user=root --host=127.0.0.1
      	--port=$MASTER_MYPORT master-bin.000002 >> $MYSQLTEST_VARDIR/tmp/remote.sql
      
      In a case when row annotations are enabled the data gets spread across four
      binary logs. As test uses only the first two binary log files, data available in
      other binary logs gets missed. Hence test fails with result content mismatch as
      less data is avaialble.
      
      Fix:
      ====
      Use "-to-the-last" option of "mysqlbinlog" tool which will ensure that all the
      available binary log specific contents are included in .sql file.
      47637a3d
  2. 13 May, 2019 12 commits
  3. 12 May, 2019 1 commit
  4. 11 May, 2019 5 commits
  5. 10 May, 2019 10 commits
    • Michal Schorm's avatar
      Update FSF address · 17b4f999
      Michal Schorm authored
      This commit is based on the work of Michal Schorm, rebased on the
      earliest MariaDB version.
      
      Th command line used to generate this diff was:
      
      find ./ -type f \
        -exec sed -i -e 's/Foundation, Inc., 59 Temple Place, Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \
        -exec sed -i -e 's/Foundation, Inc. 59 Temple Place.* Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \
        -exec sed -i -e 's/MA.*.....-1307.*USA/MA 02110-1335 USA/g' {} \; \
        -exec sed -i -e 's/Foundation, Inc., 59 Temple/Foundation, Inc., 51 Franklin/g' {} \; \
        -exec sed -i -e 's/Place, Suite 330, Boston, MA.*02111-1307.*USA/Street, Fifth Floor, Boston, MA 02110-1335 USA/g' {} \; \
        -exec sed -i -e 's/MA.*.....-1307/MA 02110-1335/g' {} \;
      17b4f999
    • Monty's avatar
      Fixed compiler warning in pcregrep.c · a89f199c
      Monty authored
      a89f199c
    • Marko Mäkelä's avatar
      MDEV-17540 Server crashes in row_purge after TRUNCATE TABLE · 8ce702aa
      Marko Mäkelä authored
      row_purge_upd_exist_or_extern_func(): Check for node->vcol_op_failed()
      after row_purge_remove_sec_if_poss(), like row_purge_del_mark() did.
      This avoids us dereferencing the node->table=NULL pointer.
      
      The test case, submitted by Elena Stepanova, is not deterministic and
      does not repeat the bug on 10.2. With the added loop, for me, it reliably
      crashes 10.3 without the fix. I was unable to create a deterministic
      test case for either 10.2 or 10.3.
      
      Reviewed by Thirunarayanan Balathandayuthapani
      8ce702aa
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · b2f3755c
      Marko Mäkelä authored
      b2f3755c
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-13893 encryption.innodb-redo-badkey failed in buildbot with page cannot be decrypted · 3e8cab51
      Thirunarayanan Balathandayuthapani authored
      buf_dblwr_process(): Remove the useless warning that a copy of a page
      in the doublewrite buffer is corrupted. We already report an error if a
      corrupted page cannot be recovered from the doublewrite buffer.
      
      Note: In MariaDB 10.1, the original bug reported in MDEV-13893 could
      still be easily repeatable. In MariaDB 10.2.24, MDEV-12699 should
      have reduced the probability considerably.
      3e8cab51
    • Marko Mäkelä's avatar
      MDEV-18220: race condition in fts_get_table_name() · 542f3264
      Marko Mäkelä authored
      fts_get_table_name(): Add the parameter bool dict_locked=false.
      542f3264
    • Marko Mäkelä's avatar
      MDEV-18220: Backport some code from MariaDB 10.2 · f3718a11
      Marko Mäkelä authored
      fts_get_table_name(): Output to a caller-allocated buffer.
      
      fts_get_table_name_prefix(): Use the lower-overhead allocation
      ut_malloc() instead of mem_alloc().
      
      This is based on mysql/mysql-server@d1584b9f38ff0bcf609d181db35f74108e022168
      in MySQL 5.7.4.
      f3718a11
    • Marko Mäkelä's avatar
      MDEV-18220: heap-use-after-free in fts_get_table_name_prefix() · f92749ed
      Marko Mäkelä authored
      fts_table_t::parent: Remove the redundant field. Refer to
      table->name.m_name instead.
      
      fts_update_sync_doc_id(), fts_update_next_doc_id(): Remove
      the redundant parameter table_name.
      
      fts_get_table_name_prefix(): Access the dict_table_t::name.
      FIXME: Ensure that this access is always covered by
      dict_sys->mutex.
      f92749ed
    • Marko Mäkelä's avatar
      MDEV-18220: Remove some redundant data structures · 5b3f7c0c
      Marko Mäkelä authored
      fts_state_t, fts_slot_t::state: Remove. Replaced by fts_slot_t::running
      and fts_slot_t::table_id as follows.
      
      FTS_STATE_SUSPENDED: Removed (unused).
      
      FTS_STATE_EMPTY: Removed. table_id=0 will denote empty slots.
      
      FTS_STATE_RUNNING: Equivalent to running=true.
      
      FTS_STATE_LOADED, FTS_STATE_DONE: Equivalent to running=false.
      
      fts_slot_t::table: Remove. Tables will be identified by table_id.
      After opening a table, we will check fil_table_accessible() before
      accessing the data.
      
      fts_optimize_new_table(), fts_optimize_del_table(),
      fts_optimize_how_many(), fts_is_sync_needed():
      Remove the parameter tables, and use the static variable fts_slots
      (which was introduced in MariaDB 10.2) instead.
      5b3f7c0c
    • Eugene Kosov's avatar
      MDEV-19399 do not call slow my_timer_init() several times · 06442e3e
      Eugene Kosov authored
      No functional change.
      
      Call my_timer_init() only once and then reuse it from InnoDB and
      perfschema storage engines.
      
      This patch speeds up empty test for me like this:
      ./mtr -mem innodb.kevg,xtradb  1.21s user 0.84s system 34% cpu 5.999 total
      ./mtr -mem innodb.kevg,xtradb  1.12s user 0.60s system 31% cpu 5.385 total
      06442e3e
  6. 09 May, 2019 1 commit