-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Storage
-
Fully Compatible
-
ALL
-
-
Repl 2019-02-11, Repl 2019-02-25, Storage NYC 2019-03-25
In the attached concurrency workload, multi-statement transactions simulate transferring money between accounts by subtracting some amount from a document's "balance" field and adding it to another document's balance, periodically asserting the sum of all balances never changes (through a collection scan in a transaction with snapshot read concern).
The workload also concurrently updates other fields in these documents outside of a transaction and when run against a sharded cluster, it fails because the sum of all balances does change, implying one of the updates from a committed transaction was lost. Every thread observes the unexpected sum, so this doesn't seem to be an issue with reading at the wrong timestamp, and the non-transaction updates don't modify the "balance" field and use $set, not replacement updates.
This failure goes away if updates set ignore_prepare=false (currently set to true here), but from talking with the replication team, they don't believe this should be required for local updates. If that's true, then it's possible the non-transaction updates are somehow overwriting the updates of committed prepared transactions.
- has to be done before
-
SERVER-38436 Add concurrency workload for majority writes concurrent with prepared transactions
- Closed
- related to
-
WT-4580 Abort transactions that perform updates with ignore_prepare=true
- Closed
-
SERVER-39996 Setting ignorePrepared should happen outside of waitForReadConcern
- Closed