1. 20 Dec, 2017 1 commit
    • Marko Mäkelä's avatar
      MDEV-14717 RENAME TABLE in InnoDB is not crash-safe · 0bc36758
      Marko Mäkelä authored
      InnoDB in MariaDB 10.2 appears to only write MLOG_FILE_RENAME2
      redo log records during table-rebuilding ALGORITHM=INPLACE operations.
      We must write the records for any .ibd file renames, so that the
      operations are crash-safe.
      
      If InnoDB is killed during a RENAME TABLE operation, it can happen that
      the transaction for updating the data dictionary will be rolled back.
      But, nothing will roll back the renaming of the .ibd file
      (the MLOG_FILE_RENAME2 only guarantees roll-forward), or for that matter,
      the renaming of the dict_table_t::name in the dict_sys cache. We introduce
      the undo log record TRX_UNDO_RENAME_TABLE to fix this.
      
      fil_space_for_table_exists_in_mem(): Remove the parameters
      adjust_space, table_id and some code that was trying to work around
      these deficiencies.
      
      fil_name_write_rename(): Write a MLOG_FILE_RENAME2 record.
      
      dict_table_rename_in_cache(): Invoke fil_name_write_rename().
      
      trx_undo_rec_copy(): Set the first 2 bytes to the length of the
      copied undo log record.
      
      trx_undo_page_report_rename(), trx_undo_report_rename():
      Write a TRX_UNDO_RENAME_TABLE record with the old table name.
      
      row_rename_table_for_mysql(): Invoke trx_undo_report_rename()
      before modifying any data dictionary tables.
      
      row_undo_ins_parse_undo_rec(): Roll back TRX_UNDO_RENAME_TABLE
      by invoking dict_table_rename_in_cache(), which will take care
      of both renaming the table and the file.
      0bc36758
  2. 19 Dec, 2017 7 commits
    • Marko Mäkelä's avatar
      Follow-up to MDEV-13407 innodb.drop_table_background failed in buildbot with... · 88aff5f4
      Marko Mäkelä authored
      Follow-up to MDEV-13407 innodb.drop_table_background failed in buildbot with "Tablespace for table exists"
      
      The InnoDB background DROP TABLE queue is something that we should
      really remove, but are unable to until we remove dict_operation_lock
      so that DDL and DML operations can be combined in a single transaction.
      
      Because the queue is not persistent, it is not crash-safe. We should
      in some way ensure that the deferred-dropped tables will be dropped
      after server restart.
      
      The existence of two separate transactions complicates the error handling
      of CREATE TABLE...SELECT. We should really not break locks in DROP TABLE.
      
      Our solution to these problems is to rename the table to a temporary
      name, and to drop such-named tables on InnoDB startup. Also, the
      queue will use table IDs instead of names from now on.
      
      check-testcase.test: Ignore #sql-ib*.ibd files, because tables may enter
      the background DROP TABLE queue shortly before the test finishes.
      
      innodb.drop_table_background: Test CREATE...SELECT and the creation of
      tables whose file name starts with #sql-ib.
      
      innodb.alter_crash: Adjust the recovery, now that the #sql-ib tables
      will be dropped on InnoDB startup.
      
      row_mysql_drop_garbage_tables(): New function, to drop all #sql-ib tables
      on InnoDB startup.
      
      row_drop_table_for_mysql_in_background(): Remove an unnecessary and
      misplaced call to log_buffer_flush_to_disk(). (The call should have been
      after the transaction commit. We do not care about flushing the redo log
      here, because the table would be dropped again at server startup.)
      
      Remove the entry from the list after the table no longer exists.
      
      If server shutdown has been initiated, empty the list without actually
      dropping any tables. They will be dropped again on startup.
      
      row_drop_table_for_mysql(): Do not call lock_remove_all_on_table().
      Instead, if locks exist, defer the DROP TABLE until they do not exist.
      If the table name does not start with #sql-ib, rename it to that prefix
      before adding it to the background DROP TABLE queue.
      88aff5f4
    • Marko Mäkelä's avatar
      Merge 10.2 into bb-10.2-ext · 028e91f3
      Marko Mäkelä authored
      028e91f3
    • Marko Mäkelä's avatar
      Merge 10.1 to 10.2 · 8d70097c
      Marko Mäkelä authored
      Follow-up fix to MDEV-14008: Let Field_double::val_uint() silently
      return 0 on error
      8d70097c
    • Jan Lindström's avatar
      Fix galera.view test case crash. · 252e690c
      Jan Lindström authored
      WSREP_TO_ISOLATION_BEGIN() call must be after view name is back
      on tables list.
      252e690c
    • Galina Shalygina's avatar
      MDEV-14629: failing assertion when a user-defined variable is defined by the recursive CTE · 079c3599
      Galina Shalygina authored
      During the user-defined variable defined by the recursive CTE handling procedure
      check_dependencies_in_with_clauses that checks dependencies between the tables
      that are defined in the CTE and find recursive definitions wasn't called.
      079c3599
    • Daniel Black's avatar
    • Daniel Black's avatar
      64f1fab0
  3. 18 Dec, 2017 12 commits
  4. 17 Dec, 2017 2 commits
    • Alexey Botchkov's avatar
      MDEV-14593 human-readable XA RECOVER. · 0acac4fe
      Alexey Botchkov authored
              The 'data' field in the XA RECOVER resultset changed
              to be charset_bin. It seems to me right and also
              --binary-as-hex starts working.  The XA RECOVER FORMAT='SQL' option
              implemented.  It returns the XID string that fits to be an argument for the
              XA ... statements.
      0acac4fe
    • Monty's avatar
      Fixed memory leak in my_rocks · 06f0b23a
      Monty authored
      rocksdb_sys_vars.rocksdb_update_cf_options_basic.test failed with
      reports about not freed memory.
      06f0b23a
  5. 16 Dec, 2017 2 commits
  6. 15 Dec, 2017 1 commit
    • Sergei Petrunia's avatar
      MDEV-14293: MyRocks lacks basic functionality · 64b11e61
      Sergei Petrunia authored
      The error
        "Unsupported collation on string indexed column %s Use
          binary collation (latin1_bin, binary, utf8_bin)."
      
      is misleading. Change it:
      - It is now a warning
      - It is printed only for collations that do not support index-only access
        (reversible collations that use unpack_info are ok)
      - The new warning text is:
      
        Indexed column %s.%s uses a collation that does not allow index-only
        access in secondary key and has reduced disk space efficiency
        in primary key.
      64b11e61
  7. 14 Dec, 2017 5 commits
  8. 13 Dec, 2017 10 commits