[MDEV-26041] Recovery failure due to delete-marked SYS_FIELDS record Created: 2021-06-29  Updated: 2021-07-05  Resolved: 2021-06-29

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.6.2
Fix Version/s: 10.6.3

Type: Bug Priority: Blocker
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: regression, rr-profile-analyzed

Issue Links:
Problem/Incident
is caused by MDEV-25506 Atomic DDL: .frm file is removed and ... Closed

 Description   

We got a recovery failure like this:

10.6 63e9a05440953bf451ebe1cd808ca445e4c7634e

mariadbd: /mariadb/10.6/storage/innobase/dict/dict0dict.cc:2028: dberr_t dict_index_add_to_cache(dict_index_t *&, ulint, const dict_add_v_col_t *): Assertion `index->n_def == index->n_fields' failed.

The reason is that for the clustered index of a #sql-ib table (which was being dropped in a transaction that had not been committed), the only SYS_FIELDS record is delete-marked. The following fixup to MDEV-25506 part 3 ought to fix it:

diff --git a/storage/innobase/dict/drop.cc b/storage/innobase/dict/drop.cc
index ff8e108b26d..1217a5bc0a1 100644
--- a/storage/innobase/dict/drop.cc
+++ b/storage/innobase/dict/drop.cc
@@ -209,13 +209,13 @@ dberr_t trx_t::drop_table(const dict_table_t &table)
                       "WHILE 1 = 1 LOOP\n"
                       "  FETCH idx INTO iid;\n"
                       "  IF (SQL % NOTFOUND) THEN EXIT; END IF;\n"
-                      "  DELETE FROM SYS_FIELDS WHERE INDEX_ID=iid;\n"
                       "  DELETE FROM SYS_INDEXES WHERE CURRENT OF idx;\n"
+                      "  DELETE FROM SYS_FIELDS WHERE INDEX_ID=iid;\n"
                       "END LOOP;\n"
                       "CLOSE idx;\n"
 
-                      "DELETE FROM SYS_COLUMNS WHERE TABLE_ID=:id;\n"
                       "DELETE FROM SYS_TABLES WHERE ID=:id;\n"
+                      "DELETE FROM SYS_COLUMNS WHERE TABLE_ID=:id;\n"
 
                       "END;\n", FALSE, this);
 }


Generated at Thu Feb 08 09:42:18 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.