WT wants to enforce that RTS take exclusive access on a table to remove any unstable updates to avoid producing inconsistent results with a cursor operation that operates in parallel to it. With that enforcement, we get the following failure from some of the MDB tests.
[j0:s0:n0] | 2021-07-06T02:17:35.057+00:00 E STORAGE 22435 [BackgroundSync] "WiredTiger error","attr":{"error":16,"message":"[1625537855:57609][7280:0x7f6701201700], file:_mdb_catalog.wt, txn rollback_to_stable: __rollback_to_stable_btree_apply, 1518: file:_mdb_catalog.wt: unable to open handle, error indicates handle is unavailable due to concurrent use: Device or resource busy"}
[j0:s0:n0] | 2021-07-06T02:17:35.057+00:00 F - 23093 [BackgroundSync] "Fatal assertion","attr":{"msgid":31049,"error":"UnrecoverableRollbackError: Error rolling back to stable. Err: Device or resource busy","file":"src/mongo/db/repl/storage_interface_impl.cpp","line":1346}
[j0:s0:n0] | 2021-07-06T02:17:35.057+00:00 F - 23094 [BackgroundSync] "\n\n***aborting after fassert() failure\n\n"
[j0:s0:n0] | 2021-07-06T02:17:35.057+00:00 F CONTROL 4757800 [BackgroundSync] "Writing fatal message","attr":{"message":"Got signal: 6 (Aborted).\n"}
This ticket is to find out to close all open cursors before calling WT RTS API?
- is related to
-
SERVER-88944 Use something better than the GlobalLock to protect storage engine access
-
- Backlog
-
- related to
-
WT-8429 Improve error handling when rollback_to_stable fails
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
WT-7507
Update salvage for a history store and timestamp world
-
- Closed
-