1. 22 Jul, 2019 5 commits
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · 60c790d6
      Marko Mäkelä authored
      60c790d6
    • Marko Mäkelä's avatar
      MDEV-20102 Phantom InnoDB table remains after interrupted CREATE...SELECT · a5e268a2
      Marko Mäkelä authored
      This is a regression due to MDEV-16515 that affects some versions in
      the MariaDB 10.1 server series starting with 10.1.35, and possibly
      all versions starting with 10.2.17, 10.3.8, and 10.4.0.
      
      The idea of MDEV-16515 is to allow DROP TABLE to be interrupted,
      in case it was stuck due to some concurrent activity. We already
      made some cases of internal DROP TABLE immune to kill in MDEV-18237,
      MDEV-16647, MDEV-17470. We must include the cleanup of
      CREATE TABLE...SELECT in the list of such internal DROP TABLE.
      
      ha_innobase::delete_table(): Pass create_failed=true if the current
      SQL statement is CREATE, so that the table will be dropped.
      
      row_drop_table_for_mysql(): If create_failed=true, do not allow
      the operation to be interrupted.
      a5e268a2
    • Nikita Malyavin's avatar
      MDEV-17005 ASAN heap-use-after-free in innobase_get_computed_value · 12614af1
      Nikita Malyavin authored
      This is the race between DELETE and INSERT (or other any two operations accessing to the table).
      What should happen in good case:
      1. ALTER TABLE is issued. vc_templ->default_rec is initialized with temporary share's default_fields
      2. temporary share is freed, but datadict is still there, with garbage in vc_templ->default_rec
      3. DELETE is issued. It is first after ALTER TABLE finished.
      4. ha_innobase::open() is called, ib_table->get_ref_count() should be one
      5. we reinitialize vc_templ, so no garbage anymore
      
      What actually happens:
      3. DELETE is issued.
      4. ha_innobase::open() is called and ib_table->get_ref_count() is 1
      5. INSERT (or SELECT etc.) is issued in parallel
      6. ha_innobase::open() is called and ib_table->get_ref_count() is 1
      7. we check ib_table->get_ref_count()  and it is 2 in both threads when we want reinitialize vc_templ
      8. garbage is there
      
      Fix:
      * Do not store pointers to SHARE memory in table dict, copy it instead.
      * But then we don't need to refresh it each time when refcount=1.
      12614af1
    • Nikita Malyavin's avatar
    • Julius Goryavsky's avatar
      The test for the wsrep_info plugin needs the same flexible wsrep version... · f27a0043
      Julius Goryavsky authored
      The test for the wsrep_info plugin needs the same flexible wsrep version checking as the tests for Galera (continuation of MDEV-18565 task)
      f27a0043
  2. 21 Jul, 2019 1 commit
  3. 20 Jul, 2019 1 commit
  4. 19 Jul, 2019 7 commits
  5. 18 Jul, 2019 12 commits
  6. 17 Jul, 2019 1 commit
    • Julius Goryavsky's avatar
      MDEV-18565: Galera mtr-suite fails if galera library is not installed · 4e02e502
      Julius Goryavsky authored
      Currently, running mtr with an incorrect (for example, new or
      obsolete) version of wsrep_provider (for example, with the 26
      version of libgalera_smm.so) leads to the failure of tests in
      several suites with vague error diagnostics.
      
      As for the galera_3nodes suite, the mtr also does not effectively
      check all the prerequisites after merge with MDEV-18426 fixes.
      For example, tests that using mariabackup do not check for presence
      of ss and socat/nc. This is due to improper handling of relative
      paths in mtr scripts.
      
      In addition, some tests in different suites can be run without
      setting the environment variables such as MTR_GALERA_TFMT, XBSTREAM,
      and so on.
      
      To eliminate all these issues, this patch makes the following changes:
      
      1. Added auxiliary wsrep_mtr_check utility (which located in the
      mysql-test/lib/My/SafeProcess subdirectory), which compares the
      versions of the wsrep API that used by the server and by the wsrep
      provider library, and it does this comparison safely, without
      accessing the API if the versions do not match.
      
      2. All checks related to the presence of mariabackup and utilities
      that necessary for its operation transferred from the local directories
      of different mtr suites (from the suite.pm files) to the main suite.pm
      file. This not only reduces the amount of code and eliminates duplication
      of identical code fragments, but also avoids problems due to the inability
      of mtr to consider relative paths to include files when checking skip
      combinations.
      
      3. Setting the values of auxiliary environment variables that
      are necessary for Galera, SST scripts and mariabackup (to work
      properly) is moved to the main mysql-test-run.pl script, so as
      not to duplicate this code in different suites, and to avoid
      partial corrections of the same errors for different suites
      (while other suites remain uncorrected).
      
      4. Fixed duplication of the have_file_key_management.inc and
      have_filekeymanagement.inc files between different suites,
      these checks are also transferred to the top level.
      
      5. Added garbd presence check and garbd path variable.
      
      https://jira.mariadb.org/browse/MDEV-18565
      4e02e502
  7. 16 Jul, 2019 6 commits
  8. 15 Jul, 2019 4 commits
    • Sergei Petrunia's avatar
      Disable rocksdb.shutdown test · d2f094d9
      Sergei Petrunia authored
      It was introduced by this patch in fb/mysql-5.6:
      Author: Yoshinori Matsunobu <yoshinori@fb.com>
      Date:   Mon Jun 10 14:09:28 2019 -0700
      
          Extending SHUTDOWN query to support read_only/aborting
      
          Summary:
          This diff extends SHUTDOWN query to support the following
          features.
          - Aborting with any specified exit code (range is 0..255).
          If nothing is specified or 0 is given, it does default clean
          shutdown. If 1+ is given, exits with the given error code
          immediately. This is helpful to shutting down instance
          even if it is stuck somewhere.
      
      MariaDB doesn't support SHUTDOWN statement or have any other way
      to exit the server process.
      d2f094d9
    • Sergei Petrunia's avatar
      1da84412
    • Sujatha's avatar
      MDEV-11154: Write_on_release_cache(log_event.cc) function will not write... · 10ebdb7f
      Sujatha authored
      MDEV-11154: Write_on_release_cache(log_event.cc) function will not write "COMMIT", if use "mysqlbinlog ... | mysql ..."
      
      Problem:
      =======
      Executing command, "mysqlbinlog --read-from-remote-server --host='xx.xx.xx.xx'
      --port=3306 --user=xxx --password=xxx --database=mysql --to-last-log
      mysql-bin.000001 --start-position=1098699 --stop-never |mysql -uxxx -pxxx", we
      found that last data read from remote couldn't commit.
      
      Analysis:
      ========
      The purpose of 'Write_on_release_cache' is that the contents of the Cache will
      automatically be written to a dedicated result file on destruction. Flush
      operation on the result file is controlled by a flag 'FLUSH_F'. Events which
      require force flush upon their destruction will have to enable this
      'Write_on_release_cache::FLUSH_F'. At present the 'FLUSH_F' flag is defined as
      an enum as shown below.
      
      enum flag
      {
        FLUSH_F
      };
      
      Since 'FLUSH_F' is the first member without initialization it get the default
      value '0'. Because of this the following flush condition never succeeds.
      
      if (m_flags & FLUSH_F)
        fflush(m_file);
      
      At present the file gets flushed only during my_fclose(result_file) operation.
      When continuous streaming is enabled through --stop-never option it never gets
      flushed and hence events are not replicated.
      
      Fix:
      ===
      Initialize the enum value to non zero value.
      10ebdb7f
    • Jan Lindström's avatar
      MDEV-19746: Galera test failures because of wsrep_slave_threads identification · ec49976e
      Jan Lindström authored
      Problem was that tests select INFORMATION_SCHEMA.PROCESSLIST processes
      from user system user and empty state. Thus, there is not clear
      state for slave threads.
      
      Changes:
      - Added new status variables that store current amount of applier threads
      (wsrep_applier_thread_count) and rollbacker threads
      (wsrep_rollbacker_thread_count). This will make clear how many slave threads
      of certain type there is.
      - Added THD state "wsrep applier idle" when applier slave thread is
      waiting for work. This makes finding slave/applier threads easier.
      - Added force-restart option for mtr to always restart servers between tests
      to avoid race on start of the test
      - Added wait_condition_with_debug to wait until the passed statement returns
      true, or the operation times out. If operation times out, the additional error
      statement will be executed
      
      Changes to be committed:
      	new file:   mysql-test/include/force_restart.inc
      	new file:   mysql-test/include/wait_condition_with_debug.inc
      	modified:   mysql-test/mysql-test-run.pl
      	modified:   mysql-test/suite/galera/disabled.def
      	modified:   mysql-test/suite/galera/r/MW-336.result
      	modified:   mysql-test/suite/galera/r/galera_kill_applier.result
      	modified:   mysql-test/suite/galera/r/galera_var_slave_threads.result
      	new file:   mysql-test/suite/galera/t/MW-336.cnf
      	modified:   mysql-test/suite/galera/t/MW-336.test
      	modified:   mysql-test/suite/galera/t/galera_kill_applier.test
      	modified:   mysql-test/suite/galera/t/galera_parallel_autoinc_largetrx.test
      	modified:   mysql-test/suite/galera/t/galera_parallel_autoinc_manytrx.test
      	modified:   mysql-test/suite/galera/t/galera_var_slave_threads.test
      	modified:   mysql-test/suite/wsrep/disabled.def
      	modified:   mysql-test/suite/wsrep/r/variables.result
      	modified:   mysql-test/suite/wsrep/t/variables.test
      	modified:   sql/mysqld.cc
      	modified:   sql/wsrep_mysqld.cc
      	modified:   sql/wsrep_mysqld.h
      	modified:   sql/wsrep_thd.cc
      	modified:   sql/wsrep_var.cc
      ec49976e
  9. 14 Jul, 2019 2 commits
  10. 12 Jul, 2019 1 commit
    • Sergei Petrunia's avatar
      MDEV-14455: rocksdb.2pc_group_commit failed in buildbot · fbbc2354
      Sergei Petrunia authored
      Use RocksDB debug sync points to introduce a sync delay. This
      commits to get grouped even when the datadir is on ramdisk.
      
      For some unclear reason the effect is visible on write_prepared
      but not write_committed, so run the test only with write_prepared.
      fbbc2354