Summary:
The work in WT-4715 and WT-5082 (to be more aggressive about rolling back transactions in threads that have been co-opted to help with eviction, but are holding the oldest timestamp in the system), used the fact that a transaction ID had been allocated to decide if a transaction was read-only or not. That's not correct in all cases, and this ticket replaces that test with a better one.
Debug table logging allocates transaction IDs for all operations. Read-only operations that set a "read_timestamp" will log a debug record, and consequently allocate a transaction ID. The operation then becomes eligible for being aborted due to high cache pressure, returning WT_ROLLBACK to the caller.
This breaks an assumption by MongoDB that read-only operations will not return WT_ROLLBACK.
- is related to
-
WT-4715 Workloads will stall if old transaction or timestamp pinned by thread co-opted for eviction
- Closed
-
WT-5082 Application threads are tasked with eviction even when pinning the oldest transaction ID
- Closed
- related to
-
WT-8790 Only allow read-only transactions in reset_snapshot
- Closed
-
SERVER-44870 MongoDB to allow WiredTiger to return WT_ROLLBACK for all transactions
- Backlog