[SERVER-32518] Establish snapshot timestamp for readConcern snapshot Created: 02/Jan/18 Updated: 30/Oct/23 Resolved: 05/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.2 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Storage 2018-02-12 |
| Participants: |
| Description |
|
Establish a snapshot timestamp if not provided via "atClusterTime" / "afterClusterTime" or by a previously stashed snapshot. In waitForReadConcern(), if readConcernLevel is snapshot, check whether getArgsPointInTime() returns boost::none, which signifies a snapshot time has yet to be established. If this is the case then we need to establish a replica set snapshot time:
Add handling for "atClusterTime" to waitForReadConcern():
|
| Comments |
| Comment by Githook User [ 05/Feb/18 ] |
|
Author: {'email': 'tess.avitabile@mongodb.com', 'name': 'Tess Avitabile', 'username': 'tessavitabile'}Message: |
| Comment by James Wahlin [ 02/Jan/18 ] |
|
I expect that we don't have to explicitly check whether atClusterTime is older than the oldest WiredTiger snapshot and that the storage engine will return an error on attempting to start a WT transaction. We should test for this and make sure that error is handled gracefully. We should explicitly confirm that atClusterTime is not ahead of the majority commit timestamp. |
| Comment by Tess Avitabile (Inactive) [ 02/Jan/18 ] |
|
james.wahlin, as part of this ticket, should we verify that the atClusterTime timestamp is not older than the oldest WiredTiger snapshot or ahead of the majority commit timestamp? |