1. 17 Jan, 2019 5 commits
  2. 16 Jan, 2019 6 commits
  3. 15 Jan, 2019 7 commits
  4. 14 Jan, 2019 8 commits
  5. 13 Jan, 2019 1 commit
  6. 10 Jan, 2019 1 commit
  7. 09 Jan, 2019 1 commit
    • Vladislav Vaintroub's avatar
      MDEV-18185 - mariabackup - fix specific case of table rename handing in prepare. · 4a872ae1
      Vladislav Vaintroub authored
      If, during backup
      1) Innodb table is dropped (after being copied to backup) and then
      2) Before backup finished, another Innodb table is renamed, and new name
      is the name of the dropped table in 1)
      
      then, --prepare fails with assertion, as DDL fixup code in prepare
      did not handle this specific case.
      
      The fix is to process drops before renames, in prepare DDL-"redo" phase.
      4a872ae1
  8. 08 Jan, 2019 1 commit
  9. 07 Jan, 2019 1 commit
    • Jan Lindström's avatar
      MDEV-15740: InnoDB does not flush redo log when it shoul · 1d56d875
      Jan Lindström authored
      During database recovery, a transaction with wsrep XID is
      recovered from InnoDB in prepared state. However, when the
      transaction is looked up with trx_get_trx_by_xid() in
      innobase_commit_by_xid(), trx->xid gets cleared in
      trx_get_trx_by_xid_low() and commit time serialization history
      write does not update the wsrep XID in trx sys header for
      that recovered trx. As a result the transaction gets
      committed during recovery but the wsrep position does not
      get updated appropriately.
      
      As a fix, we preserve trx->xid for Galera over transaction
      commit in recovery phase.
      
      Fix authored by: Teemu Ollakka (GaleraCluster) and Marko Mäkelä.
      
      	modified:   mysql-test/suite/galera/disabled.def
      	modified:   mysql-test/suite/galera/r/galera_gcache_recover_full_gcache.result
      	modified:   mysql-test/suite/galera/r/galera_gcache_recover_manytrx.result
      	modified:   mysql-test/suite/galera/t/galera_gcache_recover_full_gcache.test
      	modified:   mysql-test/suite/galera/t/galera_gcache_recover_manytrx.test
      	modified:   storage/innobase/trx/trx0trx.cc
      	modified:   storage/xtradb/trx/trx0trx.cc
      1d56d875
  10. 06 Jan, 2019 1 commit
    • Varun Gupta's avatar
      MDEV-13784: query causes seg fault · d0d0f88f
      Varun Gupta authored
      When we have a nested subquery then a subquery that was a dependent subquery
      may change to an independent one when we optimizer the inner subqueries.
      This is handled st_select_lex::optimize_unflattened_subqueries.
      Currently a subquery that was changed to independent from dependent after optimization
      phase incorrectly shows dependent in the output of Explain, this happens because we
      don't update used_tables for the WHERE clause, ON clause, etc after the optimization phase.
      d0d0f88f
  11. 04 Jan, 2019 3 commits
  12. 03 Jan, 2019 5 commits
    • Marko Mäkelä's avatar
      Fix a merge error in the parent commit · 23e4446a
      Marko Mäkelä authored
      Fix an inadvertently inverted condition that caused
      galera.galera_sst_mariabackup_table_options test failure.
      23e4446a
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · b7392d14
      Marko Mäkelä authored
      b7392d14
    • Marko Mäkelä's avatar
      MDEV-18129 Backup fails for encrypted tables: mariabackup: Database page... · 7158edcb
      Marko Mäkelä authored
      MDEV-18129 Backup fails for encrypted tables: mariabackup: Database page corruption detected at page 1
      
      If an encrypted table is created during backup, then
      mariabackup --backup could wrongly fail.
      
      This caused a failure of the test mariabackup.huge_lsn once on buildbot.
      
      This is due to the way how InnoDB creates .ibd files. It would first
      write a dummy page 0 with no encryption information. Due to this,
      xb_fil_cur_open() could wrongly interpret that the table is not encrypted.
      Subsequently, page_is_corrupted() would compare the computed page
      checksum to the wrong checksum. (There are both "before" and "after"
      checksums for encrypted pages.)
      
      To work around this problem, we introduce a Boolean option
      --backup-encrypted that is enabled by default. With this option,
      Mariabackup will assume that a nonzero key_version implies that the
      page is encrypted. We need this option in order to be able to copy
      encrypted tables from MariaDB 10.1 or 10.2, because unencrypted pages
      that were originally created before MySQL 5.1.48 could contain nonzero
      garbage in the fields that were repurposed for encryption.
      
      Later, MDEV-18128 would clean up the way how .ibd files are created,
      to remove the need for this option.
      
      page_is_corrupted(): Add missing const qualifiers, and do not check
      space->crypt_data unless --skip-backup-encrypted has been specified.
      
      xb_fil_cur_read(): After a failed page read, output a page dump.
      7158edcb
    • Sergei Golubchik's avatar
      Merge branch '10.1' into 10.2 · 842402e4
      Sergei Golubchik authored
      842402e4
    • Sergei Golubchik's avatar
      Merge branch '10.0' into 10.1 · 3ba3f81a
      Sergei Golubchik authored
      3ba3f81a