For now I'll make it a fatal error to rollback once you got to logOp, since today, once you get there, you shouldn't need to rollback.
We will want to fix the listeners soon since the plan is that rollbacks will be able to happen at any time, but that can happen outside of the critical path of enabling rollback. The tricky listeners will be the role-graph adjuster and the sharding tracker of deletes for migrations.
- is depended on by
-
SERVER-17250 logOp rollback when legacy insert creates a namespace and then fails to insert the document (fatal assertion)
- Closed
- is duplicated by
-
SERVER-17265 thread convoys from WiredTigerRecoveryUnit::registerChange
- Closed
- is related to
-
SERVER-18822 Sharded clusters with WiredTiger primaries may lose writes during chunk migration
- Closed
-
SERVER-30240 remove incorrect paragraph from getNextOpTime() comments in oplog.cpp
- Closed
- related to
-
SERVER-15774 findAndModify triggers rollback invariant failure with --notablescan
- Closed
-
SERVER-16322 Make sure that RecoveryUnit::commit() can safely throw WriteConflictException
- Closed
-
SERVER-17303 concurrent findAndModify ops with upsert: true can cause a fatal logOp() rollback
- Closed
-
SERVER-17198 logOp rollback in findAndModify when query for modified document fails (fatal assertion)
- Closed
-
SERVER-13896 Replace logOp() with a more operation-aware observer interface
- Closed