1. 02 Jul, 2020 1 commit
    • MikkoJaakola's avatar
      MDEV-22966- Hang on galera_toi_truncate test case · 7b8319f3
      MikkoJaakola authored
      galera_toi_truncate test launches a long term INSERT statement in node 2,
      and then submits an offending TRUNCATE through node 1. The idea is that
      the replicated TRUNCATE will conflict with INSERT in node 2, and force
      the INSERT to abort.
      
      The test first issues --send INSERT in node 2, and then switches to node 1
      to launch --send TRUNCATE. As the INSERT is launched asynchronously by --send,
      it may happen that INSERT has not yet started to process, before the TRUNCATE
      is replicated. The net effect may be that TRUCATE processes to completion in node 2,
      and only after that INSERT starts to execute. As the INSERT is very long query,
      it will last longer than mtr test suite max test time, the test will fail for timeout.
      
      The fix in this commit uses another connection in node 2, to wait until the INSERT
      has started to process in node 2. TRUNCATE in node 1, will be submitted in node 1
      after this wait condition.
      7b8319f3
  2. 30 Jun, 2020 3 commits
  3. 27 Jun, 2020 2 commits
  4. 25 Jun, 2020 1 commit
  5. 24 Jun, 2020 4 commits
    • Jan Lindström's avatar
    • Jan Lindström's avatar
      bffa8264
    • sjaakola's avatar
      MDEV-22632 wsrep XID checkpointing can happen out of order for certification failure · 33de71c2
      sjaakola authored
      When a transaction fails in certification phase, it has connsumed one GTID, but as
      transaction must rollback, it will not go for commit ordering, and because of this
      also the wsrep XID checkpointing can happen out of order.
      This PR will make the thread, which has failed for certiication failure to wait for its
      commit order turn for checkpointing wsrep IXD in innodb rollback segment.
      
      There is a specific test for wsrep XID checkpointing ordering in mtr test:
      mysql-wsrep-bugs-607, which is added in this PR.
      
      Test galera_slave_replay depends also on this fix, as the second test phase
      may also assert for bad wsrep XID checkpointing order.
      galera_slave_replay.test had also other problems, which caused the test to
      fail immediately, thse are now fixes in this PR as well.
      33de71c2
    • Sergei Petrunia's avatar
      MDEV-22993: Crash on EXPLAIN with PUSHED DOWN SELECT and subquery · b4abe7c9
      Sergei Petrunia authored
      - select_describe() should not attempt to produce query plans
        for subqueries if the query is handled by a Select Handler.
      
      - JOIN::save_explain_data_intern should not add links to Explain_select
        for children selects if:
        1. The whole query is handled by the Select Handler, or
        2. this select (and so its children) is handled by Derived Handler.
      b4abe7c9
  6. 23 Jun, 2020 1 commit
  7. 22 Jun, 2020 2 commits
  8. 19 Jun, 2020 1 commit
  9. 18 Jun, 2020 4 commits
  10. 17 Jun, 2020 4 commits
  11. 16 Jun, 2020 2 commits
    • Sachin's avatar
      MDEV-22370 safe_mutex: Trying to lock uninitialized mutex at... · 592a10d0
      Sachin authored
      MDEV-22370 safe_mutex: Trying to lock uninitialized mutex at /data/src/10.4-bug/sql/rpl_parallel.cc, line 470 upon shutdown during FTWRL
      
      Problem:- When we issue FTWRL with shutdown in parallel, there is race between
      FTWRL and shutdown. Shutdown might destroy the mutex (pool->LOCK_rpl_thread_pool)
      before FTWRL can lock it. So we can get crash on FTWRL thread
      
      Solution:- mysql_mutex_destroy(pool->LOCK_rpl_thread_pool) should wait for
      FTWRL thread to complete its work , and then destroy.
      So slave_prepare_for_shutdown will just deactivate the pool, and mutex is destroyed
      later in end_slave()
      592a10d0
    • MikkoJaakola's avatar
      MDEV-21759 galera.galera_parallel_autoinc_manytrx sporadic failures. · 0128e13e
      MikkoJaakola authored
      The galera.galera_parallel_autoinc_manytrx mtr test opens and runs test
      scenario through 3 connections to node 1 and one connection to node 2.
      In the test initialization phase, the test creates two tables 't1' and 'ten'
      and then creates a stored procedure 'p1' to operate on these tables.
      These 3 create DDL statements are issued through same connection to node 1.
      
      In the next test phase, the mtr script uses send command to launch the call
      for the p1 stored procedure through all 3 connections to node 1 and through
      one connection to node 2. As the mtr send command is asynchronous,
      this test phase is non blocking and fast operation.
      Now, if the replication between nodes is slow, it may happen that the
      initialization phase DDL statements have not been received or have not been
      fully applied in node 2. Therefore there is no guarantee that the test tables
      and the stored procedure have been created in node 2. Yet, the test is trying
      to call p1 in node 2.
      
      In the failure case error logs, there is error message
      "MTR failed: query 'reap' failed: 1305: PROCEDURE test.p1 does not exist"
      
      The reap command through connection to node 2, is the first place where test
      execution may observe that test tables and/or stored procedure are not yet
      created in node 2.
      
      The fix in this commit adds a wait condition in connection to node 2, to wait
      until the stored procedure is created before calling the stored procedure.
      The wait is implemented by looking in information_schema.routines for the p1
      stored procedure.
      0128e13e
  12. 15 Jun, 2020 1 commit
  13. 14 Jun, 2020 4 commits
    • Vlad Lesin's avatar
      MDEV-18215: mariabackup does not report unknown command line options · 9bdf35e9
      Vlad Lesin authored
      MDEV-21298: mariabackup doesn't read from the [mariadbd] and [mariadbd-X.Y]
      server option groups from configuration files
      MDEV-21301: mariabackup doesn't read [mariadb-backup] option group in
      configuration file
      
      All three issues require to change the same code, that is why their
      fixes are joined in one commit.
      
      The fix is in invoking load_defaults_or_exit() and handle_options() for
      backup-specific groups separately from client-server groups to let the last
      handle_options() call fail on unknown backup-specific options.
      
      The order of options procesing is the following:
      1) Load server groups and process server options, ignore unknown
      options
      2) Load client groups and process client options, ignore unknown
      options
      3) Load backup groups and process client-server options, exit on
      unknown option
      4) Process --mysqld-args command line options, ignore unknown options
      
      New global flag my_handle_options_init_variables was added to have
      ability to invoke handle_options() for the same allowed options set
      several times without re-initialising previously set option values.
      
      --password value destroying is moved from option processing callback to
      mariabackup's handle_options() function to have ability to invoke server's
      handle_options() several times for the same possible allowed options
      set.
      
      Galera invokes wsrep_sst_mariabackup.sh with mysqld command line
      options to configure mariabackup as close to the server as possible.
      It is not known what server options are supported by mariabackup when the
      script is invoked. That is why new mariabackup option "--mysqld-args" is added,
      all unknown options that follow this option will be silently ignored.
      
      wsrep_sst_mariabackup.sh was also changed to:
      - use "--mysqld-args" mariabackup option to pass mysqld options,
      - remove deprecated innobackupex mode,
      - remove unsupported mariabackup options:
          --encrypt
          --encrypt-key
          --rebuild-indexes
          --rebuild-threads
      9bdf35e9
    • Marko Mäkelä's avatar
      Merge commit 10.3 into 10.4 · ceaa8b64
      Marko Mäkelä authored
      ceaa8b64
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 32b34cb9
      Marko Mäkelä authored
      32b34cb9
    • Marko Mäkelä's avatar
      MDEV-22889: Disable innodb.innodb_force_recovery_rollback · 2cd6afb0
      Marko Mäkelä authored
      The test case that was added for MDEV-21217
      (commit b68f1d84)
      should have only two possible outcomes for the locking SELECT statement:
      
      (1) The statement is blocked, and the test will eventually fail
      with a lock wait timeout. This is what I observed when the
      code fix for MDEV-21217 was missing.
      
      (2) The lock conflict will ensure that the statement will execute
      after the rollback has completed, and an empty table will be observed.
      This is the expected outcome with the recovery fix.
      
      What occasionally happens (in some of our CI environments only, so far)
      is that the locking SELECT will return all 1,000 rows of the table that
      had been inserted by the transaction that was never supposed to be
      committed. One possibility is that the transaction was unexpectedly
      committed when the server was killed.
      
      Let us disable the test until the reason of the failure has been
      determined and addressed.
      2cd6afb0
  14. 13 Jun, 2020 5 commits
  15. 12 Jun, 2020 2 commits
  16. 11 Jun, 2020 3 commits