- 10 Sep, 2019 1 commit
-
-
Marko Mäkelä authored
The test mariabackup.encrypted_page_corruption was hard-wired for innodb_checksum_algorithm=crc32. Enable a combination for full_crc32 for the sake of completeness.
-
- 08 Sep, 2019 1 commit
-
-
Elena Stepanova authored
-
- 07 Sep, 2019 1 commit
-
-
Sergei Petrunia authored
Update test results
-
- 06 Sep, 2019 2 commits
-
-
Sergei Petrunia authored
Support Create_time and Update_time for MyRocks tables. - Create_time is stored in the MyRocks' internal data dictionary. - Update_time is in-memory only (like in InnoDB).
-
Sergei Golubchik authored
-
- 05 Sep, 2019 3 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
trx_t::is_recovered: Revert most of the changes that were made by the merge of MDEV-15326 from 10.2. The trx_sys.rw_trx_hash and the recovery of transactions at startup is quite different in 10.3. trx_free_at_shutdown(): Avoid excessive mutex protection. Reading fields that can only be modified by the current thread (owning the transaction) can be done outside mutex. trx_t::commit_state(): Restore a tighter assertion. trx_rollback_recovered(): Clarify why there is no potential race condition with other transactions. lock_trx_release_locks(): Merge with trx_t::release_locks(), and avoid holding lock_sys.mutex unnecessarily long. rw_trx_hash_t::find(): Remove redundant code, and avoid starving the committer by checking trx_t::state before trx_t::reference().
-
- 04 Sep, 2019 14 commits
-
-
Marko Mäkelä authored
-
Sergei Golubchik authored
this is not ideal and needs to be fixed eventually, but it's consistent over all forms of INSERT.
-
Sergei Golubchik authored
MDEV-20403 Assertion `0' or Assertion `btr_validate_index(index, 0)' failed in row_upd_sec_index_entry or error code 126: Index is corrupted upon UPDATE with TIMESTAMP..ON UPDATE remove a special treatment of a bare DEFAULT keyword that made it behave inconsistently and differently from DEFAULT(column). Now all forms of the explicit assignment of a default column value behave identically, and all count as an explicitly assigned value (for the purpose of ON UPDATE NOW). followup for c7c481f4
-
Sachin authored
Fix the test case.
-
Sergei Golubchik authored
MDEV-20079 When setting back the system time while mysqld is running, NOW() and UNIX_TIMESTAMP() results get stuck typo. system_time.start wasn't updated when system_time.sec and system_time.sec_part were.
-
Sergei Golubchik authored
-
Monty authored
MDEV-5817 query cache bug (returning inconsistent/old result set) with aria table parallel inserts, row format = page The problem is that for transactional aria tables (row_type=PAGE and transactional=1), maria_lock_database() didn't flush the state or the query cache. Not flushing the state is correct for transactional tables as this is done by checkpoint, but not flushing the query cache was wrong and could cause concurrent SELECT queries to not be deleted from the cache. Fixed by introducing a flush of the query cache as part of commit, if the table has changed. t for transactional aria tables (row_type=PAGE and transactional=1), maria_lock_table() didn't flush their state or the query cache.
-
Marko Mäkelä authored
Backport the applicable part of Sergey Vojtovich's commit 0ca2ea1a from MariaDB Server 10.3. trx reference counter was updated under mutex and read without any protection. This is both slow and unsafe. Use atomic operations for reference counter accesses.
-
Marko Mäkelä authored
MySQL 5.7.9 (and MariaDB 10.2.2) introduced a race condition between InnoDB transaction commit and the conversion of implicit locks into explicit ones. The assertion failure can be triggered with a test that runs 3 concurrent single-statement transactions in a loop on a simple table: CREATE TABLE t (a INT PRIMARY KEY) ENGINE=InnoDB; thread1: INSERT INTO t SET a=1; thread2: DELETE FROM t; thread3: SELECT * FROM t FOR UPDATE; -- or DELETE FROM t; The failure scenarios are like the following: (1) The INSERT statement is being committed, waiting for lock_sys->mutex. (2) At the time of the failure, both the DELETE and SELECT transactions are active but have not logged any changes yet. (3) The transaction where the !other_lock assertion fails started lock_rec_convert_impl_to_expl(). (4) After this point, the commit of the INSERT removed the transaction from trx_sys->rw_trx_set, in trx_erase_lists(). (5) The other transaction consulted trx_sys->rw_trx_set and determined that there is no implicit lock. Hence, it grabbed the lock. (6) The !other_lock assertion fails in lock_rec_add_to_queue() for the lock_rec_convert_impl_to_expl(), because the lock was 'stolen'. This assertion failure looks genuine, because the INSERT transaction is still active (trx->state=TRX_STATE_ACTIVE). The problematic step (4) was introduced in mysql/mysql-server@e27e0e0bb75b4d35e87059816f1cc370c09890ad which fixed something related to MVCC (covered by the test innodb.innodb-read-view). Basically, it reintroduced an error that had been mentioned in an earlier commit mysql/mysql-server@a17be6963fc0d9210fa0642d3985b7219cdaf0c5: "The active transaction was removed from trx_sys->rw_trx_set prematurely." Our fix goes along the following lines: (a) Implicit locks will released by assigning trx->state=TRX_STATE_COMMITTED_IN_MEMORY as the first step. This transition will no longer be protected by lock_sys_t::mutex, only by trx->mutex. This idea is by Sergey Vojtovich. (b) We detach the transaction from trx_sys before starting to release explicit locks. (c) All callers of trx_rw_is_active() and trx_rw_is_active_low() must recheck trx->state after acquiring trx->mutex. (d) Before releasing any explicit locks, we will ensure that any activity by other threads to convert implicit locks into explicit will have ceased, by checking !trx_is_referenced(trx). There was a glitch in this check when it was part of lock_trx_release_locks(); at the end we would release trx->mutex and acquire lock_sys->mutex and trx->mutex, and fail to recheck (trx_is_referenced() is protected by trx_t::mutex). (e) Explicit locks can be released in batches (LOCK_RELEASE_INTERVAL=1000) just like we did before. trx_t::state: Document that the transition to COMMITTED is only protected by trx_t::mutex, no longer by lock_sys_t::mutex. trx_rw_is_active_low(), trx_rw_is_active(): Document that the transaction state should be rechecked after acquiring trx_t::mutex. trx_t::commit_state(): New function to change a transaction to committed state, to release implicit locks. trx_t::release_locks(): New function to release the explicit locks after commit_state(). lock_trx_release_locks(): Move much of the logic to the caller (which must invoke trx_t::commit_state() and trx_t::release_locks() as needed), and assert that the transaction will have locks. trx_get_trx_by_xid(): Make the parameter a pointer to const. lock_rec_other_trx_holds_expl(): Recheck trx->state after acquiring trx->mutex, and avoid a redundant lookup of the transaction. lock_rec_queue_validate(): Recheck impl_trx->state while holding impl_trx->mutex. row_vers_impl_x_locked(), row_vers_impl_x_locked_low(): Document that the transaction state must be rechecked after trx_mutex_enter(). trx_free_prepared(): Adjust for the changes to lock_trx_release_locks().
-
Marko Mäkelä authored
This is a backport of 900b0790 from MariaDB Server 10.3.
-
Marko Mäkelä authored
We were missing a test that would exercise trx_free_prepared() with innodb_fast_shutdown=0. Add a test. Note: if shutdown hangs due to the XA PREPARE transactions, in MariaDB 10.2 the test would unfortunately pass, but take 2*60 seconds longer, because of two shutdown_server statements timing out after 60 seconds. Starting with MariaDB 10.3, the hung server would be killed with SIGABRT, and the test could fail thanks to a backtrace message.
-
Marko Mäkelä authored
-
Alexander Barkov authored
-
Jan Lindström authored
-
- 03 Sep, 2019 9 commits
-
-
Eugene Kosov authored
-
Eugene Kosov authored
get_col_list_to_be_dropped() incorrectly returned uninteresting instantly dropped column which was missing in a new dict_index_t get_col_list_to_be_dropped(): rename to collect_columns_from_dropped_indexes and stop return dropped columns
-
Sergei Golubchik authored
-
Sergei Golubchik authored
MDEV-20403 Assertion `0' or Assertion `btr_validate_index(index, 0)' failed in row_upd_sec_index_entry or error code 126: Index is corrupted upon UPDATE with TIMESTAMP..ON UPDATE Three issues here: * ON UPDATE DEFAULT NOW columns were updated after generated columns were computed - this broke indexed virtual columns * ON UPDATE DEFAULT NOW columns were updated after BEFORE triggers, so triggers didn't see the correct NEW value * in case of a multi-update generated columns were also updated after BEFORE triggers
-
Sergei Golubchik authored
on UPDATE, compare_record() was comparing all columns that are marked for writing. But generated columns that are written to the table are always deterministic and cannot change unless normal non-generated columns were changed. So it's enough to compare only non-generated columns that were explicitly assigned values in the SET clause.
-
Sergei Golubchik authored
* remove one level of virtual functions * remove redundant checks * remove an if() as the value is always known at compilation time don't pretend that "DEFAULT expr" and "ON UPDATE DEFAULT NOW" are "basically the same thing"
-
Monty authored
-
Alexander Barkov authored
Part2: MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH This patch allows the server to open old tables that have "bad" generated columns (i.e. indexed virtual generated columns, persistent generated columns) that depend on sql_mode, for general things like SELECT, INSERT, DROP, etc. Warning are issued in such cases. Only these commands are now disallowed and return an error: - CREATE TABLE introducing a "bad" generated column - ALTER TABLE introducing a "bad" generated column - CREATE INDEX introdicing a "bad" generated column (i.e. adding an index on a virtual generated column that depends on sql_mode). Note, these commands are allowed: - ALTER TABLE removing a "bad" generate column - ALTER TABLE removing an index from a "bad" virtual generated column - DROP INDEX removing an index from a "bad" virtual generated column but only if the table does not have any "bad" columns as a result.
-
Alexander Barkov authored
MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH This change takes into account a column's GENERATED ALWAYS AS expression dependcy on sql_mode's PAD_CHAR_TO_FULL_LENGTH and NO_UNSIGNED_SUBTRACTION flags. Indexed virtual columns as well as persistent generated columns are now not allowed to have such dependencies to avoid inconsistent data or index files on sql_mode changes. So an error is now returned in cases like this: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (a) PERSISTENT -- CHAR->VARCHAR or CHAR->TEXT = ERROR ); Functions RPAD() and RTRIM() can now remove dependency on PAD_CHAR_TO_FULL_LENGTH. So this can be used instead: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (RTRIM(a)) PERSISTENT ); Note, unlike CHAR->VARCHAR and CHAR->TEXT this still works, not RPAD(a) is needed: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v CHAR(5) AS (a) PERSISTENT -- CHAR->CHAR is OK ); More sql_mode flags may affect values of generated columns. They will be addressed separately. See comments in sql_mode.h for implementation details.
-
- 02 Sep, 2019 6 commits
-
-
Monty authored
-
Oleksandr Byelkin authored
-
Ian Gilfillan authored
Changes for 10.4 only, please null-merge to 10.5
-
Sergei Petrunia authored
Use EITS statistics to avoid changing query plans
-
Oleksandr Byelkin authored
-
Varun Gupta authored
-
- 01 Sep, 2019 3 commits
-
-
Varun Gupta authored
-
Monty authored
This allows one to run the test suite even if any of the following options are changed: - character-set-server - collation-server - join-cache-level - log-basename - max-allowed-packet - optimizer-switch - query-cache-size and query-cache-type - skip-name-resolve - table-definition-cache - table-open-cache - Some innodb options etc Changes: - Don't print out the value of system variables as one can't depend on them to being constants. - Don't set global variables to 'default' as the default may not be the same as the test was started with if there was an additional option file. Instead save original value and reset it at end of test. - Test that depends on the latin1 character set should include default_charset.inc or set the character set to latin1 - Test that depends on the original optimizer switch, should include default_optimizer_switch.inc - Test that depends on the value of a specific system variable should set it in the test (like optimizer_use_condition_selectivity) - Split subselect3.test into subselect3.test and subselect3.inc to make it easier to set and reset system variables. - Added .opt files for test that required specfic options that could be changed by external configuration files. - Fixed result files in rockdsb & tokudb that had not been updated for a while.
-
Monty authored
-