1. 05 May, 2017 25 commits
  2. 12 Apr, 2017 1 commit
  3. 10 Apr, 2017 1 commit
  4. 09 Apr, 2017 2 commits
  5. 08 Apr, 2017 4 commits
  6. 07 Apr, 2017 7 commits
    • Alexander Barkov's avatar
    • Alexander Barkov's avatar
      fa5be1d3
    • Alexander Barkov's avatar
    • Monty's avatar
      Simple binary cache optimizations · 0177a9c7
      Monty authored
      - Don't call my_chsize() for small (less than 64K) binary log tmp files
      - Don't flush cache to disk on reset.
      0177a9c7
    • Monty's avatar
      Simple cleanups · 1bcfa14e
      Monty authored
      - Added file name to error in mysql-test-run
      - When creating tags, first do it for sql to make it easier to find things in server
      1bcfa14e
    • Marko Mäkelä's avatar
      MDEV-10139 Support for InnoDB SEQUENCE objects · 7c767a30
      Marko Mäkelä authored
      We introduce a NO_ROLLBACK flag for InnoDB tables. This flag only works
      for tables that have a single index. Apart from undo logging, this flag
      will also prevent locking and the assignment of DB_ROW_ID or DB_TRX_ID,
      and imply READ UNCOMMITTED isolation. It is assumed that the SQL layer
      is guaranteeing mutual exclusion.
      
      After the initial insert of the single record during CREATE SEQUENCE,
      InnoDB will be updating the single record in-place. This is crash-safe
      thanks to the redo log. (That is, after a crash after CREATE SEQUENCE
      was committed, the effect of sequence operations will be observable
      fully or not at all.)
      
      When it comes to the durability of the updates of SEQUENCE in
      InnoDB, there is a clear analogy to MDEV-6076 Persistent AUTO_INCREMENT.
      The updates would be made persistent by the InnoDB redo log flush
      at transaction commit or rollback (or XA PREPARE), provided that
      innodb_log_flush_at_trx_commit=1.
      
      Similar to AUTO_INCREMENT, it is possible that the update of a SEQUENCE
      in a middle of transaction becomes durable before the COMMIT/ROLLBACK of
      the transaction, in case the InnoDB redo log is being flushed as a result
      of the a commit or rollback of some other transaction, or as a result of
      a redo log checkpoint that can be initiated at any time by operations that
      are writing redo log.
      
      dict_table_t::no_rollback(): Check if the table does not support rollback.
      
      BTR_NO_ROLLBACK: Logging and locking flags for no_rollback() tables.
      
      DICT_TF_BITS: Add the NO_ROLLBACK flag.
      
      row_ins_step(): Assign 0 to DB_ROW_ID and DB_TRX_ID, and skip
      any locking for no-rollback tables. There will be only a single row
      in no-rollback tables (or there must be a proper PRIMARY KEY).
      
      row_search_mvcc(): Execute the READ UNCOMMITTED code path for
      no-rollback tables.
      
      ha_innobase::external_lock(), ha_innobase::store_lock():
      Block CREATE/DROP SEQUENCE in innodb_read_only mode.
      This probably has no effect for CREATE SEQUENCE, because already
      ha_innobase::create() should have been called (and refused)
      before external_lock() or store_lock() is called.
      
      ha_innobase::store_lock(): For CREATE SEQUENCE, do not acquire any
      InnoDB locks, even though TL_WRITE is being requested. (This is just
      a performance optimization.)
      
      innobase_copy_frm_flags_from_create_info(), row_drop_table_for_mysql():
      Disable persistent statistics for no_rollback tables.
      7c767a30
    • Monty's avatar
      Change error message when using DROP VIEW on a non existing view from · 470c3fd9
      Monty authored
      "Unknown table" to "Unknown view"
      470c3fd9