mariadb/mysql-test/suite/maria/maria-autozerofill.result

81 lines
2.3 KiB
Text
Raw Normal View History

Fixed some mysql-test-run failures and compile warnings/errors Added logging of all possible fatal table errors if --log-warnings set to > 1 mysql-test/extra/rpl_tests/rpl_EE_err.test: Safety fix mysql-test/extra/rpl_tests/rpl_row_basic.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/r/archive.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/r/csv.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/maria/r/maria-autozerofill.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/maria/t/maria-autozerofill.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/maria/t/maria-recover.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/parts/t/partition_recover_myisam.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/r/rpl_bug38694.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/r/rpl_idempotency.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/r/rpl_ignore_table.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/r/rpl_row_basic_11bugs.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/r/rpl_row_conflicts.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/r/rpl_temporary_errors.result: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/t/rpl_bug38694.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/t/rpl_idempotency.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/t/rpl_ignore_table.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/t/rpl_row_basic_11bugs.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/t/rpl_row_conflicts.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/suite/rpl/t/rpl_temporary_errors.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/t/archive.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) mysql-test/t/csv.test: Added suppression of possible error message (so that one can run test with --log-warnings=2) sql/handler.cc: If running with --assert-of-crashed-table or --log-warnings > 1 then print engine error to log sql/sql_select.cc: Disable not initialized warning from gcc strings/Makefile.am: Fixed compiler error on Solaris 10 (duplicate strmov() function)
2011-01-20 18:08:12 +01:00
call mtr.add_suppression("Table 't1' is marked as crashed and should be repaired");
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
drop database if exists mysqltest;
create database mysqltest;
connect admin, localhost, root,,mysqltest,,;
connection default;
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
use mysqltest;
2010-09-12 18:40:01 +02:00
create table t1(a int) engine=aria;
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
insert into t1 values(1);
2012-03-28 12:49:07 +02:00
create table t2 (a int) engine=aria;
INSERT INTO t2 VALUES (1),(2);
2012-03-28 12:49:07 +02:00
create table t3 (a int) engine=aria;
INSERT INTO t3 VALUES (1),(2);
2012-03-28 12:49:07 +02:00
create table t4 (a int) engine=aria;
INSERT INTO t4 VALUES (1),(2);
2012-03-30 12:54:33 +02:00
create table t5 (a int) engine=aria;
INSERT INTO t5 VALUES (1),(2);
create table t6 (a int) engine=aria;
INSERT INTO t6 VALUES (1),(2);
flush tables;
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
create_rename_lsn has non-magic value
connection default;
connection admin;
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
* shut down mysqld, removed logs, restarted it
connection default;
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
select * from t1;
a
1
Warnings:
Note 1194 Zerofilling moved table ./mysqltest/t1
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
flush table t1;
Status: changed,sorted index pages,zerofilled
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
insert into t1 values(2);
flush table t1;
create_rename_lsn has non-magic value
#
# BUG#44422 "mysql_upgrade destroys Maria tables?"
# Check repair and optimize of moved table
#
check table t2;
Table Op Msg_type Msg_text
mysqltest.t2 check error Table is from another system and must be zerofilled or repaired to be usable on this system
mysqltest.t2 check error Corrupt
check table t2;
Table Op Msg_type Msg_text
mysqltest.t2 check error Table is from another system and must be zerofilled or repaired to be usable on this system
mysqltest.t2 check error Corrupt
repair table t2;
Table Op Msg_type Msg_text
mysqltest.t2 repair status OK
check table t2;
Table Op Msg_type Msg_text
mysqltest.t2 check status OK
optimize table t3;
Table Op Msg_type Msg_text
mysqltest.t3 optimize Note Zerofilling moved table ./mysqltest/t3
mysqltest.t3 optimize status OK
analyze table t4;
Table Op Msg_type Msg_text
mysqltest.t4 analyze Note Zerofilling moved table ./mysqltest/t4
mysqltest.t4 analyze status OK
repair table t5;
Table Op Msg_type Msg_text
mysqltest.t5 repair status OK
check table t5;
Table Op Msg_type Msg_text
mysqltest.t5 check status OK
repair table t5;
Table Op Msg_type Msg_text
mysqltest.t5 repair status OK
check table t5;
Table Op Msg_type Msg_text
mysqltest.t5 check status OK
select * from t6;
a
1
2
check table t6;
Table Op Msg_type Msg_text
mysqltest.t6 check status OK
Fix for BUG#37876 "Importing Maria table from other server via binary copy does not work": - after auto-zerofill (ha_maria::check_and_repair()) kepts its state's LSNs unchanged, which could be the same as the create_rename_lsn of another pre-existing table, which would break versioning as this LSN serves as unique identifier in the versioning code (in maria_open()). Even the state pieces which maria_zerofill() did change were lost (because they didn't go to disk). - after this fix, if two tables were auto-zerofilled at the same time (by _ma_mark_changed()) they could receive the same create_rename_lsn, which would break versioning again. Fix is to write a log record each time a table is imported. - Print state's LSNs (create_rename_lsn, is_of_horizon, skip_redo_lsn) and UUID in maria_chk -dvv. mysql-test/r/maria-autozerofill.result: result mysql-test/t/maria-autozerofill.test: Test for auto-zerofilling storage/maria/ha_maria.cc: The state changes done by auto-zerofilling never reached disk. storage/maria/ma_check.c: When zerofilling a table, including its pages' LSNs, new state LSNs are needed next time the table is imported into a Maria instance. storage/maria/ma_create.c: Write LOGREC_IMPORTED_TABLE when importing a table. This is informative and ensures that the table gets a unique create_rename_lsn even though multiple tables are imported by concurrent threads (it advances the log's end LSN). storage/maria/ma_key_recover.c: comment storage/maria/ma_locking.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_loghandler.c: New type of log record storage/maria/ma_loghandler.h: New type of log record storage/maria/ma_loghandler_lsn.h: New name for constant as can be used not only by maria_chk but auto-zerofill now too. storage/maria/ma_open.c: instead of using translog_get_horizon() for state's LSNs of imported table, use the LSN of to-be-written LOGREC_IMPORTED_TABLE. storage/maria/ma_recovery.c: print content of LOGREC_IMPORTED_TABLE in maria_read_log. storage/maria/maria_chk.c: print info about LSNs of the table's state, and UUID, when maria_chk -dvv storage/maria/maria_pack.c: new name for constant storage/maria/unittest/ma_test_recovery.pl: Now that maria_chk -dvv shows state LSNs and UUID those need to be filtered out, as maria_read_log -a does not use the same as at original run.
2008-07-09 11:02:27 +02:00
drop database mysqltest;