- 21 Aug, 2017 2 commits
-
-
Jan Lindström authored
-
Jan Lindström authored
-
- 20 Aug, 2017 1 commit
-
-
Jan Lindström authored
-
- 19 Aug, 2017 1 commit
-
-
Jan Lindström authored
-
- 18 Aug, 2017 1 commit
-
-
Jan Lindström authored
-
- 17 Aug, 2017 2 commits
-
-
Marko Mäkelä authored
srv_undo_tablespaces_init(): In Mariabackup backup mode, do initialize the array of undo_tablespace_ids[].
-
Jan Lindström authored
Page read could return DB_PAGE_CORRUPTED error that should be reported and passed to upper layer. In case of unknown error code we should print both number and string.
-
- 16 Aug, 2017 3 commits
-
-
Jan Lindström authored
-
Jan Lindström authored
This is because they could cause out of storage if run on /dev/shm.
-
Jan Lindström authored
-
- 15 Aug, 2017 4 commits
-
-
Jan Lindström authored
Merged from mysql-wsrep-bugs following: GCF-1058 MTR test galera.MW-86 fails on repeated runs Wait for the sync point sync.wsrep_apply_cb to be reached before executing the test and clearing the debug flag sync.wsrep_apply_cb. The race scenario: Intended behavior: node2: set sync.wsrep_apply_cb in order to start waiting in the background INSERT node1: INSERT start node2 (background): INSERT start node1: INSERT end node2: send signal to background INSERT: "stop waiting and continue executing" node2: clear sync.wsrep_apply_cb as no longer needed node2 (background): consume the signal node2 (background): INSERT end node2: DROP TABLE node2: check no pending signals are left - ok What happens occasionally (unexpected): node2: set sync.wsrep_apply_cb in order to start waiting in the background INSERT node1: INSERT start node2 (background): INSERT start node1: INSERT end // The background INSERT still has _not_ reached the place where it starts // waiting for the signal: // DBUG_EXECUTE_IF("sync.wsrep_apply_cb", "now wait_for..."); node2: send signal to background INSERT: "stop waiting and continue executing" node2: clear sync.wsrep_apply_cb as no longer needed // The background INSERT reaches DBUG_EXECUTE_IF("sync.wsrep_apply_cb", ...) // but sync.wsrep_apply_cb has already been cleared and the "wait" code is not // executed. The signal remains unconsumed. node2 (background): INSERT end node2: DROP TABLE node2: check no pending signals are left - failure, signal.wsrep_apply_cb is pending (not consumed) Remove MW-360 test case as it is not intended for MariaDB (uses MySQL GTID).
-
Sergei Golubchik authored
-
Sergey Vojtovich authored
Follow-up to original patch: fixing test cases.
-
=Ian Gilfillan authored
-
- 14 Aug, 2017 26 commits
-
-
Sergei Golubchik authored
also fix innodb
-
Teemu Ollakka authored
-
Teemu Ollakka authored
Conflicts: mysql-test/include/kill_and_restart_mysqld.inc
-
sjaakola authored
Refs: MW-363 * enabling binlog file copying even for binlog files with basename "0" * mtr suite uses binlog files with names: 0.000001, 0.000002.. and so on
-
sjaakola authored
MW-378 enabling build with WITH_WSREP=OFF only one fix here, enables build of mysqld however, building embedded server fails in linking phase
-
sjaakola authored
Skipping wsrep extra FK checking for applier and replayer threads
-
sjaakola authored
Skipping wsrep extra FK checking for applier and replayer threads
-
Teemu Ollakka authored
-
sjaakola authored
Refs: MW-369 * fixed sync point usage in MW-369.inc, which made it impossible to run this test with --repeat option * moved all MW-369*.test tests into MW-369.test file, each as one separate test phase * added two more test phases, in MW-369.test file * tests MW-369A, MW-369B and MW-369C are obsolete after this commit
-
Teemu Ollakka authored
-
sjaakola authored
Refs: MW-369 * changed parent row key type to S(hared), when FK child table is being updated or deleted
-
Teemu Ollakka authored
Tests MW-369C, MW-369D haven't been recorded yet since the outcome from the tests is not what is desired.
-
sjaakola authored
-
sjaakola authored
-
sjaakola authored
Refs: MW-369 * added MTR test, which causes a crash in slave applying, due to FK constraint violation * mtr test is not deterministic, but can surface the crash, at least in my laptop
-
Philip Stoev authored
-
Philip Stoev authored
-
Philip Stoev authored
-
Daniele Sciascia authored
Sync waiting before processing SQLCOM_REPLACE was not necessary given that this case falls through to processing of SQLCOM_INSERT. In case of SQLCOM_REPLACE, wsrep_sync_wait would be called twice.
-
Philip Stoev authored
-
Philip Stoev authored
-
Daniele Sciascia authored
The following commands are now subject to wsrep_sync_wait with bitmask value 8: SHOW BINARY LOGS SHOW BINLOG EVENTS SHOW GRANTS
-
Philip Stoev authored
Galera MTR Tests: Tests for MW-360 DROP TABLE containing temporary tables results in binlog divergence
-
sjaakola authored
-
Daniele Sciascia authored
-
Daniele Sciascia authored
-