Loading...

XML

Word

Printable

JSON

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.
acquireCollectionWithoutLocks checksShardingPlacement, it is correct.
Collection becomes sharded from some other client running shardCollection.
acquireCollectionWithoutLocks 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.
acquireCollectionWithoutLocks checksShardingPlacement again and everything checks out 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~~ in the AutoGetCollectionForLockFreeReads case, however it might be broken, see ~~SERVER-76559~~.

is related to

SERVER-62457 Lock-free reads causes query subsystem to treat unsharded collection as sharded when collection is dropped and re-created (ABA problem)

SERVER-76559 Lock-free reads can read from sharded collection as unsharded when collection is dropped and recreated (ABA problem)

Participants:: [DO NOT USE] Backlog - Catalog and Routing, Daniel Gomez Ferro