With the completion of SERVER-38548 making index drops two-phase, we can now remove the special handling where we rebuild indexes on rollback because the index table was dropped immediately and the dropIndex gets rolled back.
I believe this code in kv_storage_engine.cpp does the special handling and can now be eliminated safely.
And in this bit, it should also be safe to refactor away the "!foundIdent" piece. Dan G's explanation of that scenario was as follows, which won't happen anymore either with SERVER-38548 complete,
"
Suppose the oplog contains:
ts: 10, createIndex: "a"
ts: 30, dropIndex: "a"
If the secondary completes the background index and timestamps the `ready: true` write at ts: 20, rolling back to 25 will show a `ready: true` index, but no underlying table because it was dropped. (edited)
"
Note: A good way to test that those code paths are inactive might be to add some invariants that they never occur anymore and run a full evergreen patch.
- depends on
-
SERVER-33161 Postpone WiredTigerKVEngine table drops until the _mdb_catalog change is checkpointed
- Closed
- is depended on by
-
SERVER-37637 Standalone mode nodes should ignore in-progress index builds on startup
- Closed
- is related to
-
SERVER-55397 Index build restart ident drops are not timestamped during startup recovery
- Closed
-
SERVER-37966 Do not wait for index build completion on startup
- Closed
-
SERVER-38702 Set up FCV for simultaneous index builds
- Closed
- related to
-
SERVER-38548 Leverage the KVDropPendingIdentReaper and TimestampMonitor to make index drops two-phase
- Closed