-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
ALL
-
-
Storage NYC 2019-04-08, Storage NYC 2019-04-22
-
0
This came out of SERVER-39689, where we test that a transaction prepared before the stable timestamp will still be in prepare after a rollback. When we commit this transaction, the counts do not reflect the insert of the prepared transaction.
My understanding is that we add to the count when we put a transaction into prepare. We then subtract from the count when we abort the storage transaction of a prepared transaction during rollback.
We do not change the counts when reconstructing the prepared transaction during recovery. This is not a problem if the prepared transaction is eventually aborted. However, if this transaction is eventually committed, the counts are incorrect.
- is depended on by
-
SERVER-40566 Fix fastcount for large transaction format in rollback
- Closed
- is related to
-
SERVER-39762 Fix fastcount after rollback recovery of prepared transactions.
- Closed
-
SERVER-40614 Rollback errors should be fatal while prepared transactions have been aborted
- Closed
- related to
-
SERVER-40517 Fastcount isn't adjusted correctly when transaction started and prepared is entirely rolled back
- Closed