mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-29 02:05:57 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/suite/innodb/t/instant_alter_purge.test

35 lines
883 B
Text
Raw Permalink Normal View History

MDEV-17793 Crash in purge after instant DROP and emptying the table There was a race condition between ALTER TABLE and purge. If a table turns out to be logically empty when instant ALTER TABLE is executing, we will convert the table to the canonical format, to avoid overhead during subsequent accesses, and to allow the data file to be imported into older versions of MariaDB. It could happen that at the time the table is logically empty, there still exists an undo log record for updating the hidden metadata record for an earlier instant ALTER TABLE operation. If the table was converted to the canonical format before purge processes this undo log record, the undo log record could be referring to index fields that no longer exist, causing a crash. To prevent the race condition, we must delete the old undo log records. We do this lazily by assigning a new table ID, so that the table lookup for the old undo log records will fail. dict_table_t::reassign_id(): Reassign the table_id to effectively lazily delete old undo log records. innobase_instant_try(): Invoke index->table->reassign_id() before index->clear_instant_alter().
2018-11-22 10:41:15 +02:00
--source include/have_innodb.inc
MDEV-17813: Fix the test for release builds
2018-11-23 18:36:44 +02:00
--source include/maybe_debug.inc
if ($have_debug) {
--source include/have_debug_sync.inc
}
MDEV-17793 Crash in purge after instant DROP and emptying the table There was a race condition between ALTER TABLE and purge. If a table turns out to be logically empty when instant ALTER TABLE is executing, we will convert the table to the canonical format, to avoid overhead during subsequent accesses, and to allow the data file to be imported into older versions of MariaDB. It could happen that at the time the table is logically empty, there still exists an undo log record for updating the hidden metadata record for an earlier instant ALTER TABLE operation. If the table was converted to the canonical format before purge processes this undo log record, the undo log record could be referring to index fields that no longer exist, causing a crash. To prevent the race condition, we must delete the old undo log records. We do this lazily by assigning a new table ID, so that the table lookup for the old undo log records will fail. dict_table_t::reassign_id(): Reassign the table_id to effectively lazily delete old undo log records. innobase_instant_try(): Invoke index->table->reassign_id() before index->clear_instant_alter().
2018-11-22 10:41:15 +02:00
MDEV-31355 innodb_undo_log_truncate=ON fails to wait for purge of enough transaction history purge_sys_t::sees(): Wrapper for view.sees(). trx_purge_truncate_history(): Invoke purge_sys.sees() instead of comparing to head.trx_no, to determine if undo pages can be safely freed. The test innodb.cursor-restore-locking was adjusted by Vladislav Lesin, as was the the debug instrumentation in row_purge_del_mark(). Reviewed by: Vladislav Lesin
2023-06-08 09:17:52 +03:00
--source include/wait_all_purged.inc
MDEV-17793 Crash in purge after instant DROP and emptying the table There was a race condition between ALTER TABLE and purge. If a table turns out to be logically empty when instant ALTER TABLE is executing, we will convert the table to the canonical format, to avoid overhead during subsequent accesses, and to allow the data file to be imported into older versions of MariaDB. It could happen that at the time the table is logically empty, there still exists an undo log record for updating the hidden metadata record for an earlier instant ALTER TABLE operation. If the table was converted to the canonical format before purge processes this undo log record, the undo log record could be referring to index fields that no longer exist, causing a crash. To prevent the race condition, we must delete the old undo log records. We do this lazily by assigning a new table ID, so that the table lookup for the old undo log records will fail. dict_table_t::reassign_id(): Reassign the table_id to effectively lazily delete old undo log records. innobase_instant_try(): Invoke index->table->reassign_id() before index->clear_instant_alter().
2018-11-22 10:41:15 +02:00
--echo #
--echo # MDEV-17793 Crash in purge after instant DROP and emptying the table
--echo #
connect (prevent_purge,localhost,root);
START TRANSACTION WITH CONSISTENT SNAPSHOT;
connection default;
MDEV-32050 fixup: Stabilize tests In any test that uses wait_all_purged.inc, ensure that InnoDB tables will be created without persistent statistics. This is a follow-up to commit cd04673a177d40f7c409284d87ead851ec775c36 after a similar failure was observed in the innodb_zip.blob test.
2023-11-21 12:42:00 +02:00
CREATE TABLE t1 (f1 INT, f2 INT) ENGINE=InnoDB STATS_PERSISTENT=0;
MDEV-17793 Crash in purge after instant DROP and emptying the table There was a race condition between ALTER TABLE and purge. If a table turns out to be logically empty when instant ALTER TABLE is executing, we will convert the table to the canonical format, to avoid overhead during subsequent accesses, and to allow the data file to be imported into older versions of MariaDB. It could happen that at the time the table is logically empty, there still exists an undo log record for updating the hidden metadata record for an earlier instant ALTER TABLE operation. If the table was converted to the canonical format before purge processes this undo log record, the undo log record could be referring to index fields that no longer exist, causing a crash. To prevent the race condition, we must delete the old undo log records. We do this lazily by assigning a new table ID, so that the table lookup for the old undo log records will fail. dict_table_t::reassign_id(): Reassign the table_id to effectively lazily delete old undo log records. innobase_instant_try(): Invoke index->table->reassign_id() before index->clear_instant_alter().
2018-11-22 10:41:15 +02:00
INSERT INTO t1 () VALUES ();
ALTER TABLE t1 DROP f2, ADD COLUMN f2 INT;
ALTER TABLE t1 DROP f1;
DELETE FROM t1;
connection prevent_purge;
COMMIT;
START TRANSACTION WITH CONSISTENT SNAPSHOT;
connection default;
ALTER TABLE t1 ADD COLUMN extra TINYINT UNSIGNED NOT NULL DEFAULT 42;
MDEV-31355 innodb_undo_log_truncate=ON fails to wait for purge of enough transaction history purge_sys_t::sees(): Wrapper for view.sees(). trx_purge_truncate_history(): Invoke purge_sys.sees() instead of comparing to head.trx_no, to determine if undo pages can be safely freed. The test innodb.cursor-restore-locking was adjusted by Vladislav Lesin, as was the the debug instrumentation in row_purge_del_mark(). Reviewed by: Vladislav Lesin
2023-06-08 09:17:52 +03:00
SET GLOBAL innodb_max_purge_lag_wait=1;
MDEV-17793 Crash in purge after instant DROP and emptying the table There was a race condition between ALTER TABLE and purge. If a table turns out to be logically empty when instant ALTER TABLE is executing, we will convert the table to the canonical format, to avoid overhead during subsequent accesses, and to allow the data file to be imported into older versions of MariaDB. It could happen that at the time the table is logically empty, there still exists an undo log record for updating the hidden metadata record for an earlier instant ALTER TABLE operation. If the table was converted to the canonical format before purge processes this undo log record, the undo log record could be referring to index fields that no longer exist, causing a crash. To prevent the race condition, we must delete the old undo log records. We do this lazily by assigning a new table ID, so that the table lookup for the old undo log records will fail. dict_table_t::reassign_id(): Reassign the table_id to effectively lazily delete old undo log records. innobase_instant_try(): Invoke index->table->reassign_id() before index->clear_instant_alter().
2018-11-22 10:41:15 +02:00
ALTER TABLE t1 DROP extra;
disconnect prevent_purge;
let $wait_all_purged= 0;
--source include/wait_all_purged.inc
DROP TABLE t1;
Reference in a new issue Copy permalink