1. 17 Jun, 2019 2 commits
  2. 16 Jun, 2019 2 commits
  3. 15 Jun, 2019 1 commit
  4. 14 Jun, 2019 6 commits
  5. 13 Jun, 2019 3 commits
  6. 12 Jun, 2019 13 commits
    • Oleksandr Byelkin's avatar
      Merge branch '5.5' into 10.1 · 5b65d61d
      Oleksandr Byelkin authored
      5b65d61d
    • Marko Mäkelä's avatar
      Clean up the test innodb.innodb-64k-crash · 06be8cd3
      Marko Mäkelä authored
      Before killing the server, ensure that the incomplete state of
      the transaction will be made durable and will be applied and
      rolled back on recovery, so that each time, roughly the same
      amount of work will be done.
      
      Remove DML statements after the recovery, and execute
      CHECK TABLE instead.
      06be8cd3
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · 1d31bed2
      Marko Mäkelä authored
      1d31bed2
    • Marko Mäkelä's avatar
      MDEV-16111 encryption.innodb_lotoftables failed in buildbot with wrong result · 56c60b2f
      Marko Mäkelä authored
      Remove the test, because it easily fails with a result difference.
      Analysis by Thirunarayanan Balathandayuthapani:
      
      By default, innodb_encrypt_tables=0.
      1) Test case creates 100 tables in innodb_encrypt_1.
      2) creates another 100 unencrypted tables (encryption=off) in innodb_encrypt_2
      3) creates another 100 encrypted tables (encryption=on) in innodb_encrypt_3
      4) enabling innodb_encrypt_tables=1 and checking that only
      100 encrypted tables exist. (already we have 100 in dictionary)
      5) opening all tables again (no idea why)
      6) After that, set innodb_encrypt_tables=0 and wait for 100 tables
      to be decrypted (already we have 100 unencrypted tables)
      7) dropping all databases
      
      Sporadic failure happens because after step 4, it could encrypt the
      normal table too, because innodb_encryption_threads=4.
      
      This test was added in MDEV-9931, which was about InnoDB startup being
      slow due to all .ibd files being opened. There have been a number of
      later fixes to this problem. Currently the latest one is
      commit cad56fba, in which some tests
      (in particular the test innodb.alter_kill) could fail if all InnoDB
      .ibd files are read during startup. That could make this test redundant.
      
      Let us remove the test, because it is big, slow, unreliable, and
      does not seem to reliably catch the problem that all files are being
      read on InnoDB startup.
      56c60b2f
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · 90fec960
      Marko Mäkelä authored
      90fec960
    • Marko Mäkelä's avatar
      MDEV-19740: Remove some broken InnoDB systemd code · 94e66559
      Marko Mäkelä authored
      GCC 9.1.1 noticed that sd_notifyf() was always being invoked with
      str=NULL argument for "%s". This code was added in
      commit 2e814d47
      but not mentioned in the commit comment.
      
      The STATUS messages for systemd matter during startup and shutdown,
      and should not be emitted during normal operation.
      
      ib_senderrf(): Remove the potentially harmful sd_notifyf() calls.
      94e66559
    • sjaakola's avatar
      MDEV-19563 Removed references to deprecated option innodb_locks_unsafe_for_binlog · efc3cb93
      sjaakola authored
      innodb_locks_unsafe_for_binlog variabe removed from wsrep_info test configuration and
      recommendation to use this variable in README-wsrep was removed as well
      
      Also relates to issue: MDEV-19544
      efc3cb93
    • Sergey Vojtovich's avatar
      MDEV-16467 - MariaDB crashes because of "long semaphore wait"after migrating from 10.1 to 10.3 · 9d886de4
      Sergey Vojtovich authored
      This patch fixes 10.2 issue reported in MDEV-16467 by partial backport of
      c2118a08. Specifically "Remove not needed LOCK_thread_count from
      thd_get_error_context_description()".
      9d886de4
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · 4bbd8be4
      Marko Mäkelä authored
      4bbd8be4
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-16866 InnoDB fails to start upon crash recovery with "[ERROR] InnoDB:... · b2f76bac
      Thirunarayanan Balathandayuthapani authored
      MDEV-16866 InnoDB fails to start upon crash recovery with "[ERROR] InnoDB: Redo log crypto: failed to decrypt log block"
      
      - Post-push fix to change the copyright of both xtradb and innodb file.
      b2f76bac
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-16866 InnoDB fails to start upon crash recovery with "[ERROR] InnoDB:... · c5fe1b8f
      Thirunarayanan Balathandayuthapani authored
      MDEV-16866 InnoDB fails to start upon crash recovery with "[ERROR] InnoDB: Redo log crypto: failed to decrypt log block"
      
      - If InnoDB encounters garbage or incomplete written log block during
      recovery then don't throw the error. Treat it as end of the log.
      - This kind of incomplete or empty block can be result of killing
      InnoDB when writing the redo log.
      c5fe1b8f
    • Jan Lindström's avatar
      Merge 10.2 into 10.3 · cf78b8c6
      Jan Lindström authored
      cf78b8c6
    • Jan Lindström's avatar
      MDEV-19736: Galera test failure on · 34b38ad7
      Jan Lindström authored
      Remove unneeded select to provider name. Provider can have different
      names and can be located on different directory on different
      environments.
      34b38ad7
  7. 11 Jun, 2019 3 commits
  8. 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
  9. 09 Jun, 2019 1 commit
    • Igor Babaev's avatar
      MDEV-19580 Unrelated JOINs corrupt usage of 'WHERE function() IN (subquery)' · 6db2ebbb
      Igor Babaev authored
      Handling of top level conjuncts in WHERE whose used_tables() contained
      RAND_TABLE_BIT in the function make_join_select() was incorrect.
      As a result if such a conjunct referred to fields non of which belonged
      to the last joined table  it was pushed twice. (This could be seen
      for a test case from subselect.test whose output was changed after this
      patch had been applied. In 10.1 when running EXPLAIN FORMAT=JSON for
      the query from this test case we clearly see that one of the conjuncts
      is pushed twice.) This fact by itself was not good. Besides, if such a
      conjunct was pushed to a table that was the result of materialization
      of a semi-join the query could return a wrong result set. In particular
      we could watch it for queries with semi-join subqueries whose left parts
      used stored functions without "deterministic' specifier.
      6db2ebbb
  10. 07 Jun, 2019 3 commits
  11. 06 Jun, 2019 5 commits