mariadb/mysql-test/suite/maria/t/maria-recovery3.test

118 lines
4.1 KiB
Text
Raw Normal View History

--source include/not_embedded.inc
# Don't test this under valgrind, memory leaks will occur as we crash
--source include/not_valgrind.inc
# Binary must be compiled with debug for crash to occur
--source include/have_debug.inc
--source include/have_maria.inc
2010-09-12 18:40:01 +02:00
set global aria_log_file_size=4294967295;
let $MARIA_LOG=../../tmp;
--disable_warnings
drop database if exists mysqltest;
--enable_warnings
create database mysqltest;
let $mms_tname=t;
# Include scripts can perform SQL. For it to not influence the main test
# they use a separate connection. This way if they use a DDL it would
# not autocommit in the main test.
connect (admin, 127.0.0.1, root,,mysqltest,,);
--enable_reconnect
connection default;
use mysqltest;
--enable_reconnect
let $mms_tables=1;
let $mvr_restore_old_snapshot=0;
let $mms_compare_physically=0;
let $mvr_debug_option="+d,maria_flush_whole_log,maria_crash";
2010-09-12 18:40:01 +02:00
let $mvr_crash_statement= set global aria_checkpoint_interval=1;
-- source include/maria_empty_logs.inc
# Test for BUG#41037 (recovery failure)
--echo * TEST of Checkpoint between writing the commit log record and committing in trnman
# we want recovery to use the tables as they were at time of crash
let $mvr_restore_old_snapshot=0;
# UNDO phase prevents physical comparison, normally,
# so we'll only use checksums to compare.
let $mms_compare_physically=0;
2010-09-12 18:40:01 +02:00
create table t1(a int primary key) engine=aria;
insert into t1 values(1);
-- source include/maria_make_snapshot_for_comparison.inc
set session debug="+d,maria_sleep_in_commit";
send insert into t1 values(2);
sleep 1;
# Now the INSERT of 2 has written a commit record
# but not yet called trnman_commit(), so for checkpoint it's not
# committed.
connection admin;
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=1000; # force a checkpoint
connection default;
reap; # end of INSERT
delete from t1 where a=2;
# Bug was that: Recovery starts REDO scanning from too far: from
# Checkpoint record which says INSERT is not committed, so
# Recovery executes the INSERT's UNDO and finds no key to delete
# (as DELETE already deleted it), fails.
-- source include/maria_verify_recovery.inc
drop table t1;
# Note that even if machine is loaded and thus INSERT is committed
# before checkpoint happens, test should still pass (though it won't
# reproduce the conditions of the bug).
2010-09-12 18:40:01 +02:00
# Test for BUG#41493 Aria: two recovery failures (wrong logging of BLOB pages)
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
--echo * TEST of logging of BLOBs
let $mvr_restore_old_snapshot=1;
let $mms_compare_physically=1;
CREATE TABLE `t1` (
`blob` blob,
`blob_key` blob
2010-09-12 18:40:01 +02:00
) ENGINE=aria ROW_FORMAT=page
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
;
-- source include/maria_make_snapshot_for_feeding_recovery.inc
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=0; # no checkpoints
Fix for BUG#41493 "Maria: two recovery failures (wrong logging of BLOB pages)" and some more debugging output related to this. mysql-test/suite/maria/r/maria-recovery3.result: result update mysql-test/suite/maria/t/maria-recovery3.test: Test for bug; before the fix, the "CHECK TABLE EXTENDED" would mention a bad bitmap, because the REDO_INSERT_ROW_BLOBS was containing a page number which was actually the one of a tail, so execution of this record would mark the tail page as full in bitmap (like if it were a blob page), though it wasn't full. Also, the assertion added around ma_blockrec.c:6580 in the present revision fired. storage/maria/ma_blockrec.c: - fix for BUG#41493: if we found out that logging was not needed at this point (blob_length==0 i.e. tail page), then we forgot to increment tmp_block, so in the second iteration (assuming two BLOB columns), we would log the page range of the first iteration (i.e. the tail page's number) for this second BLOB, which would cause Recovery to overwrite the tail page with the second BLOB. - assert when marking the table corrupted during REDO phase; this catches some problems earlier otherwise they get caught only when a later record wants to use the table. - _ma_apply_redo_insert_row_blobs() now fills some synthetic info about the blobs and pages involved in a REDO_INSERT_ROW_BLOBS record, for inclusion into maria_recovery.trace: number of blobs, of ranges, first and last page (does not tell about any gaps in the middle, but good enough for now). It also asserts that it's not overwriting a tail/head page (which happened in the bug). storage/maria/ma_blockrec.h: new prototype for _ma_apply_redo_insert_row_blobs storage/maria/ma_recovery.c: Print info got from _ma_apply_redo_insert_row_blobs() to maria_recovery.trace (so far this file had mentioned what head and tail pages a record touched, but not blob pages).
2009-01-15 16:14:47 +01:00
INSERT INTO `t1` VALUES (NULL,repeat('A',5198));
INSERT INTO `t1` VALUES (NULL,repeat('B',65535));
INSERT INTO `t1` VALUES (repeat('K',5198),repeat('L',2325));
INSERT INTO `t1` VALUES (repeat('C',65535),NULL);
INSERT INTO `t1` VALUES (NULL,repeat('D',65535));
INSERT INTO `t1` VALUES (repeat('E',65535),repeat('F',16111));
INSERT INTO `t1` VALUES (repeat('G',65535),repeat('H',65535));
INSERT INTO `t1` VALUES (repeat('I',5198),repeat('J',65535));
check table t1 extended;
-- source include/maria_make_snapshot_for_comparison.inc
-- source include/maria_verify_recovery.inc
drop table t1;
2010-09-12 18:40:01 +02:00
# Test for BUG#42112 "Aria: recovery failure (pushbuild2) Assertion
# `rownr == 0 && new_page' failed"
let $mvr_restore_old_snapshot=0;
let $mms_compare_physically=0;
2010-09-12 18:40:01 +02:00
create table t1 engine=aria select 1;
-- source include/maria_make_snapshot_for_feeding_recovery.inc
2010-09-12 18:40:01 +02:00
set global aria_checkpoint_interval=0; # no checkpoints
insert into t1 values(2);
truncate table t1;
-- source include/maria_make_snapshot_for_comparison.inc
let $mvr_crash_statement= truncate table t1;
let $mvr_debug_option="+d,maria_flush_whole_log,maria_crash_create_table";
truncate table t1;
-- source include/maria_verify_recovery.inc
# Table is bad but at least Recovery didn't crash and a new truncate
# can succeed:
truncate table t1;
check table t1 extended;
drop table t1;
# clean up everything
let $mms_purpose=feeding_recovery;
eval drop database mysqltest_for_$mms_purpose;
let $mms_purpose=comparison;
eval drop database mysqltest_for_$mms_purpose;
drop database mysqltest;