[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:
Backports
Depends
is depended on by SERVER-37560 Allow change streams to work with spe... Closed
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: SERVER-38218 AutoGetCollection doesn't need to call getPointInTimeReadTimestamp for non snapshot read concern levels
Branch: master
https://github.com/mongodb/mongo/commit/6c2879fca21a4a43c4e173115850b979b434cb88

Generated at Thu Feb 08 04:48:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.