- 05 May, 2017 25 commits
-
-
Kosov Eugene authored
-
Aleksey Midenkov authored
Moved opt_for_system_time_clause from table identifier (which binds it to single table) to table expression.
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
* BEGIN_TS(), COMMIT_TS() SQL functions; * VTQ instead of packed stores secs + usecs like my_timestamp_to_binary() does; * versioned SELECT to IB is translated with COMMIT_TS(); * SQL fixes: - FOR_SYSTEM_TIME_UNSPECIFIED condition compares to TIMESTAMP_MAX_VALUE; - segfault fix #36: multiple execute of prepared stmt; - different tables to same stored procedure fix (#39) * Fixes of previous parts: ON DUPLICATE KEY, other misc fixes.
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
These features are defined only in XtraDB: chaged_page_bitmaps, innodb_changed_pages
-
Kosov Eugene authored
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
* versioned DML: INSERT, UPDATE, DELETE; * general refactoring and fixes. Warning: breaks 'insert' and 'update' tests since they require part IV.
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
* moved vers_notify_vtq() to commit phase; * low_level insert (load test passed); * rest of SYS_VTQ columns filled: COMMIT_TS, CONCURR_TRX; * savepoints support; * I_S.INNODB_SYS_VTQ adjustments: - limit to I_S_SYS_VTQ_LIMIT(10000) of most recent records; - CONCURR_TRX limit to I_S_MAX_CONCURR_TRX(100) with '...' truncation marker; - TIMESTAMP fields show fractions of seconds.
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Kosov Eugene authored
-
Aleksey Midenkov authored
* SYS_VTQ internal InnoDB table; * I_S.INNODB_SYS_VTQ table; * vers_notify_vtq(): add record to SYS_VTQ on versioned DML; * SYS_VTQ columns filled: TRX_ID, BEGIN_TS.
-
Kosov Eugene authored
-
Kosov Eugene authored
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Aleksey Midenkov authored
-
Daniel Fiala authored
-
- 12 Apr, 2017 1 commit
-
-
Daniel Fiala authored
-
- 10 Apr, 2017 1 commit
-
-
Kosov Eugene authored
-
- 09 Apr, 2017 2 commits
-
-
Michael Widenius authored
-
Michael Widenius authored
Problem was that we got an error in sequence_insert while opening the newly created sequence table in an prepared statement as the table id didn't match. Fixed by temporarly removing the reprepare observer during sequence_insert as there can never be a table missmatch in this case.
-
- 08 Apr, 2017 4 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
-
Alexander Barkov authored
storage/rocksdb/rdb_datadic.cc failed to compile on big endian machines (wrong usage of static_assert)
-
Alexander Barkov authored
-
- 07 Apr, 2017 7 commits
-
-
Alexander Barkov authored
-
Alexander Barkov authored
-
Alexander Barkov authored
-
Monty authored
- Don't call my_chsize() for small (less than 64K) binary log tmp files - Don't flush cache to disk on reset.
-
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
-
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.
-
Monty authored
"Unknown table" to "Unknown view"
-