[SERVER-53703] [4.2] Opening a transaction at the all durable timestamp can go backwards Created: 12/Jan/21  Updated: 29/Oct/23  Resolved: 12/Jan/21

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.2.12

Type: Bug Priority: Blocker - P1
Reporter: Daniel Gottlieb (Inactive) Assignee: Daniel Gottlieb (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Sharding 2021-01-25
Participants:
Linked BF Score: 33

 Description   

SERVER-41766 introduced ghost timestamps on a primary for multi-statement transactions doing a multikey write. This causes WT's perspective of the all durable timestamp to go backwards.

To compensate, the method to get the all durable that the storage engine exposes ensures the value does not go backwards.

However, the 4.2 version of reading at the all durable timestamp uses the API that can go backwards. This can result in causal reads not seeing their own writes when they are concurrent with other writers flipping multikey inside a multi statement transaction. Reading at the no overlap, however does use from the safe API.

4.4 (and master) use the WTKVEngine call which protects them from this bug.



 Comments   
Comment by Githook User [ 12/Jan/21 ]

Author:

{'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}

Message: SERVER-53703: Use WTKVEngine to compute the all durable timestamp.
Branch: v4.2
https://github.com/mongodb/mongo/commit/d2b91684f767aa151585e7cc79bc35312acc12d7

Generated at Thu Feb 08 05:31:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.