innodb/r/read_only_recover_committed.result

connect con1, localhost, root;
CREATE TABLE t(a INT PRIMARY KEY) ENGINE=InnoDB;
INSERT INTO t VALUES(1);
BEGIN;
INSERT INTO t VALUES(2);
UPDATE t SET a=20 WHERE a=2;
connect con2, localhost, root;
# Normal MariaDB shutdown would roll back the above transaction.
# We want the transaction to remain open, so we will kill the server
# after ensuring that any non-transactional files are clean.
FLUSH TABLES;
# Create another transaction that will be recovered as COMMITTED.
BEGIN;
SET DEBUG_SYNC='after_trx_committed_in_memory SIGNAL committed WAIT_FOR ever';
COMMIT;
connection default;
SET DEBUG_SYNC='now WAIT_FOR committed';
# Ensure that the above transactions become durable.
SET GLOBAL innodb_flush_log_at_trx_commit=1;
BEGIN;
INSERT INTO t VALUES(-10000);
ROLLBACK;
# restart: --innodb-force-recovery=3
disconnect con1;
disconnect con2;
SELECT * FROM t;
a
1
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM t;
a
1
20
UPDATE t SET a=3 WHERE a=1;
# restart: --innodb-read-only
SET GLOBAL innodb_status_output= @@GLOBAL.innodb_status_output;
# Starting with MariaDB 10.2, innodb_read_only implies READ UNCOMMITTED.
# In earlier versions, this would return the last committed version
# (only a=3; no record for a=20)!
SELECT * FROM t;
a
3
20
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
SELECT * FROM t;
a
3
20
# restart: --innodb-force-recovery=5
#
# MDEV-15418 innodb_force_recovery=5 displays bogus warnings
#            about too new transaction identifier
#
# With the fix, innodb_force_recovery=5 implies READ UNCOMMITTED.
SELECT * FROM t;
a
3
20
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT * FROM t;
a
3
20
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SELECT * FROM t;
a
3
20
#
# MDEV-27332 SIGSEGV in fetch_data_into_cache
#
BEGIN;
SELECT trx_state FROM information_schema.innodb_trx;
trx_state
COMMIT;
# restart
SELECT * FROM t;
a
3
DROP TABLE t;
FOUND 1 /Rolled back recovered transaction [^0]/ in mysqld.1.err