[SERVER-33933] Confirm storage engine support for point-in-time reads in waitForReadConcern() Created: 16/Mar/18  Updated: 07/Jun/18  Resolved: 07/Jun/18

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

Type: Bug Priority: Major - P3
Reporter: James Wahlin Assignee: Asya Kamsky
Resolution: Cannot Reproduce Votes: 0
Labels: nyc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-33932 Confirm storage engine support for po... Closed
Operating System: ALL
Participants:

 Description   

Both readConcern level majority and snapshot require a storage engine that supports snapshot isolation. It is possible to bypass this check when:

  1. Running a sharded cluster with standalone shards
  2. Executing a readConcern level majority read operation with afterClusterTime

In this case, we skip calling replCoord->waitUntilOpTimeForRead() here and won't then call ReplicationCoordinatorImpl::_validateReadConcern() which will perform validation.

A proposal to fix would be to add the "if majority then isReadCommittedSupportedByStorageEngine()" check to waitForReadConcern() as a more universal check. We could then change the ReplicationCoordinatorImpl::_validateReadConcern() validation to be an invariant.



 Comments   
Comment by Asya Kamsky [ 07/Jun/18 ]

The code appears to do the right thing.

james.wahlin if I missed something in reproducing this, let me know please.  I used 4.0.0-rc3

 

Comment by Asya Kamsky [ 07/Jun/18 ]
  1. is possible.
  2. is not possible (I think as a result of SERVER-33798 maybe?)

Here is what I get:

db.test.runCommand({find: "test", readConcern: {level: "majority"}})
/* works */
db.test.runCommand({find: "test", readConcern: {level: "majority", afterClusterTime: Timestamp(1528389, 1)}})
{
    "ok" : 0,
    "errmsg" : "Encountered non-retryable error during query :: caused by :: Cannot specify afterClusterTime readConcern without replication enabled", 
    "code" : 20,
    "code" : 20,
    "codeName" : "IllegalOperation", etc...
}

Comment by Ian Whalen (Inactive) [ 01/Jun/18 ]

Assigning to asya to investigate if this is possible. If not, going to close. If so, going to route to Sharding team to consider making #1 not possible as a solution.

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