Details
-
Bug
-
Resolution: Won't Fix
-
Major - P3
-
None
-
None
-
None
-
None
-
Storage Execution
-
ALL
-
Execution Team 2023-05-15, Execution Team 2023-05-29, Execution NAMR Team 2023-06-26
Description
This is hypothetical, we haven't tried to reproduce it.
The scenario looks like this:
- Collection exists and is unsharded.
- Mongos attaches shard version UNSHARDED to the request.
- Collection becomes sharded from some other client running shardCollection.
- AutoGetCollectionLockFree opens the snapshot at this point.
- Collection is dropped from some other client running drop.
- Collection is created again as unsharded from some other client running create.
- AutoGetCollectionForReadCommandLockFree checks and sees the collection is unsharded. Then AutoGetCollectionForReadCommandBase checks the shard version and everything checks out. In particular, CollectionShardingState::checkShardVersionOrThrow() passes because the request was sent with shard version UNSHARDED and the collection is (again now) unsharded.
Currently we have a check to prevent this exact scenario described in SERVER-62457 , however it relies on the check in AutoGetCollectionForReadCommandLockFree to observe the collection as sharded, if the check happens when the collection is unsharded again the problem is not detected (presumably).
Attachments
Issue Links
- related to
-
SERVER-76561 Lock-free acquisitions can read from sharded collection as unsharded when collection is dropped and recreated (ABA problem)
-
- Blocked
-