1. 03 Jan, 2019 7 commits
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 94e22efb
      Marko Mäkelä authored
      94e22efb
    • 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
      "fix" sequence.temporary test · 8cbb0bfa
      Sergei Golubchik authored
      8cbb0bfa
    • Sergei Golubchik's avatar
      Merge branch '10.2' into 10.3 · 6bb11efa
      Sergei Golubchik authored
      6bb11efa
    • 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
  2. 02 Jan, 2019 8 commits
  3. 30 Dec, 2018 1 commit
  4. 29 Dec, 2018 7 commits
  5. 28 Dec, 2018 3 commits
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · 33caaba5
      Marko Mäkelä authored
      33caaba5
    • Eugene Kosov's avatar
      MDEV-17470 Orphan temporary files after interrupted ALTER cause InnoDB:... · c5a5eaa9
      Eugene Kosov authored
      MDEV-17470 Orphan temporary files after interrupted ALTER cause InnoDB: Operating system error number 17 and eventual fatal error 71
      
      Orphan #sql* tables may remain after ALTER TABLE
      was interrupted by timeout or KILL or client disconnect.
      
      This is a regression caused by MDEV-16515.
      
      Similar to temporary tables (MDEV-16647), we had better ignore the
      KILL when dropping the original table in the final part of ALTER TABLE.
      
      Closes #1020
      c5a5eaa9
    • Marko Mäkelä's avatar
      row_drop_table_for_mysql(): Correct a parameter to innobase_format_name() · b74eb5a5
      Marko Mäkelä authored
      This fixes a regression that was introduced in MySQL 5.6.6
      in an error handling code path, in the following change:
      
      commit 024f363d6b5f09b20d1bba411af55be95c7398d3
      Author: kevin.lewis@oracle.com <>
      Date:   Fri Jun 15 09:01:42 2012 -0500
      
          Bug #14169459 INNODB; DROP TABLE DOES NOT DELETE THE IBD FILE
          FOR A TEMPORARY TABLE.
      b74eb5a5
  6. 27 Dec, 2018 2 commits
    • Marko Mäkelä's avatar
      Follow-up to MDEV-14585: Remove dict_temp_file_num · ab4bc844
      Marko Mäkelä authored
      Now that InnoDB startup drops tables whose name starts with #sql,
      the table ID alone should be enough to create a unique table name.
      
      dict_temp_file_num, dict_mem_init(): Remove.
      
      dict_mem_create_temporary_tablename(): Use a combination of
      "#sql-ib" and the ID of the table that is being rebuilt
      in TRUNCATE TABLE, or discarded in the commit of table-rebuilding
      ALTER TABLE...ALGORITHM=INPLACE, or deferred to the DROP queue.
      
      Thanks to Sergey Vojtovich for pointing this out.
      ab4bc844
    • Teodor Mircea Ionita's avatar
      e2939795
  7. 26 Dec, 2018 1 commit
  8. 25 Dec, 2018 1 commit
  9. 24 Dec, 2018 2 commits
  10. 23 Dec, 2018 2 commits
  11. 22 Dec, 2018 1 commit
  12. 21 Dec, 2018 5 commits