[SERVER-38218] AutoGetCollection doesn't need to call getPointInTimeReadTimestamp for non snapshot read concern levels Created: 21/Nov/18 Updated: 29/Oct/23 Resolved: 21/Nov/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.6 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | William Schultz (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Requested: |
v4.0
|
||||||||||||
| Sprint: | Repl 2018-12-03 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Inside AutoGetCollection, we have a special block to check for pending catalog changes if the read concern level is kSnapshotReadConcern. We make a call to RecoveryUnit::getPointInTimeReadTimestamp before checking for snapshot read concern. This means that we may call this when trying to acquire a collection lock but the read concern is non-snapshot. This is problematic if a command that uses a non snapshot read concern tries to set a read timestamp source on the recovery unit before calling AutoGetCollection. In WiredTiger, for example, we will invariant that a read timestamp has already been set. When we take a collection lock, the read timestamp may not have been set, but this is fine. We shouldn't invariant in this case. It should be simple enough to move the call inside that if statement, so that we only call it if we are sure we have snapshot read concern. |
| Comments |
| Comment by Githook User [ 21/Nov/18 ] |
|
Author: {'name': 'William Schultz', 'email': 'william.schultz@mongodb.com', 'username': 'will62794'}Message: |